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EVALUATION 

1.  This  effort,  entitled  "Language  Control  Facility  (LCF)  Study",  was 
undertaken  to  investigate  the  tools,  procedures,  personnel,  and  facilities 
that  would  be  needed  to  effectively  control  and  standardize  a high  order 
language  used  for  computer  programming. 


2.  In  the  past,  standardization  of  such  programming  languages  usually  ended 
with  the  production  of  a language  specification.  From  that  point  on, 
implementations  of  the  language  (in  the  form  of  compilers)  produced  many 
"dialects"  or  variations.  The  occurrence  of  an  implementation  which  came 
even  close  to  the  specification  was  rare,  and  the  occurrence  of  two  identical 
implementations  was  nonexistant.  The  variations  in  the  quality  and  maintenance 
support  of  the  compilers  resulting  from  an  implementation  were  probably  even 
more  pronounced,  and  the  Air  Force  buyer  of  a compiler  was  usually  not 
guaranteed  any  minimum  performance.  A final  problem  which  often  occurred  was 
the  uncontrolled  ad  hoc  inclusion  of  new  features  because  the  language  became 
out  of  date  with  requirements  and/or  did  not  take  advantage  of  new  hardware. 

3.  In  order  to  solve  the  above  problems,  RADC  undertook  the  development  of 
several  tools  and  techniques  which  provided  the  Air  Force  with  a solution 

to  or  a good  measure  of  control  over  the  various  problem  areas  of  programming 
languages.  However,  most  of  the  tools  or  techniques  attacked  primarily  a 
single  problem  area  or  were  not  interfaceu  with  one  another,  and  it  became 
obvious  that  the  most  benefit  could  be  obtained  by  the  use  of  all  ot  the  tools 
and  techniques  in  conjunction  with  one  another. 


4.  This  effort,  which  was  performed  under  TPO  11,  "Software  Sciences 
Technology,"  evaluated  those  tools  and  techniques  with  an  eye  Itowards  uniting 
and  interfacing  them  to  perform  the  various  tasks  necessary  to  control  one 
or  more  programming  languages  in  the  most  efficient  manner  possible.  At  the 
time  of  the  release  of  this  report,  many  of  the  suggestions  for  modification 
of  the  existing  tools  were  already  underway. 


5.  With  regard  to  the  implementation  of  the  actual  facility  itself,  the 
Air  Force  has  already  initiated  plans  to  implement  a Language  Control  Facility 
along  the  guidelines  proposed  by  this  report  before  actual  completion  of  the 
study.  The  prototype  facility  will  operate  for  a two  year  trial  period  and 
will  be  responsible  for  the  dialects  of  JOVIAL  programming  language  called 
J3  and  J73. 


6.  The  concept  of  high  order  language  control 
Department  of  Defense,  and  will  be  here  on  one 
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EXECUTIVE  SUMMARY 


There  exists  within  the  computer  industry  a multitude  of  Higher-Order  Languages 
(HOLs)  developed  to  satisfy  the  requirements  of  a growing  number  of  applications. 
The  U.S.  Air  Force,  as  an  important  member  of  the  industry,  has  funded  and 
continues  to  fund  the  development  of  HOLs.  However,  lack  of  guidelines  for  a 
standardized  approach  has  resulted  in  the  development  of  HOLs  that  only  meet 
the  requirements  of  a single  user,  or  at  best,  a minimum  number  of  users. 

Because  of  the  costliness  of  developing  compilers  and  compiler  languages  for 
specific  users,  the  Rome  Air  Development  Center  (RADC)  has  conceived  the 
idea  of  a central  Language  Control  Facility  (LCF)  to  deal  with  all  the  elements 
of  the  HOLs.  The  goal  of  such  a facility  is  to  have  compilers  for  the  HOL  readily 
available  for  any  authorized  user  and  to  keep  the  HOL  and  its  compilers  up-to- 
date  with  respect  to  changing  Air  Force  requirements. 

In  addition  to  the  compiler  itself,  a significant  amount  of  software  would  also  be 
provided  by  the  LCF  to  further  support  the  HOL  and  encourage  reliance  upon  and 
use  of  the  LCF.  This  additional  software  is  used  to: 

• Automate  compiler  development  through  use  of  prototype  modules 
and  compiler  generation  tools 

• Validate  compiler  conformance  to  the  HOL  standard  anti  analyze  its 
reliability 

• Monitor  language  usage  to  assist  continual  language  growth 

• Provide  both  compile-  and  r:n-time  statistics  to  users  for  analyzing 
software  costs  and  tuning  systems 

• Perform  automatic  program  verification 

• Support  program  checkout  by  performing  HOL-level  data  generation, 
symbolic  data  reduction,  and  system  scaffolding/modeling  tools 
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This  HOL-related  software  serves  several  purposes,  primary  of  which  is  the 
reduction  of  total  software  life  cycle  costs  by  HOL  usage  and  standardization. 
This  alone  cuts  costs  by  increasing  production,  reducing  programmer  training 
(and  retraining)  requirements,  eliminating  redundant  compiler  development 
costs  and  enhancing  software  portability.  The  software  also  provides  a very 
persuasive  benefit  for  utilizing  the  LCF  support  and  resisting  application- 
dependent  language  extensions  and  the  resulting  version  proliferation.  Con- 
centration of  this  software  development  and  maintenance  under  the  LCF  permits 
spreading  the  costs  of  this  support  software  to  each  user  rather  than  burdening 
each  with  more  cost  for  historically  less  capability. 

This  two  volume  report  presents  the  results  of  a study  performed  for  RADC  by 
Computer  Sciences  Corporation  (CSC)  to  analyze  the  major  components  of  an 
LCF  and  to  make  recommendations  for  the  implementation  of  single  and  multiple 
HOLs.  In  analyzing  the  usefulness  and  cost-effectiveness  of  an  LCF,  the  fol- 
lowing components  that  would  make  up  the  facility  were  examined  in  detail: 

• Network  and  data  communications  between  the  LCF  and  the  HOL 
users 

• Hardware  and  computer  systems  required  to  host  the  LCF 

• Formal  operating  rules  and  procedures  between  the  LCF  and  HOL 
users 

• Personnel  staffing  at  the  LCF 

• Design  of  the  physical  facility 

• HOL  software  tools 

The  first  five  components  are  discussed  in  Volume  1,  and  the  software  tools 
required  to  implement,  control,  and  maintain  the  HOL  are  discussed  in  Volume 
2.  Costs  for  both  developing  and  maintaining  the  LCF  are  included  in  Volume  1. 
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NETWORK  AND  DATA  COMMUNICATIONS  BETWEEN 
THE  LCF  AND  HOL  USERS 


The  initial  task  of  the  study  group  was  to  determine  the  communications  require- 
ments between  the  LCF  and  the  HOL  users  and  to  evaluate  current  available 
communication  networks  for  applicability  in  meeting  these  requirements.  Four 
potential  LCF  communications  configurations  were  defined  and  a user  response 
time  model  was  developed  for  evaluation  purposes.  Since  the  problem  response 
time  for  manual  baseline  configurations  was  more  than  twice  that  of  the  auto- 
mated baseline  configurations,  an  automated  form  of  communications  is  recom- 
mended. However,  based  on  the  relative  costs  for  the  semi-automated 
telecommunications,  semi-automated  teleprocessors,  and  fully  automated 
configurations,  as  contrasted  with  the  relative  effectiveness,  the  semi- 
automated  teleprocessing  system  is  recommended. 

Several  existing  computer  communications  networks  then  were  investigated 
to  select  the  optimum  network  for  LCF  implementation.  Based  on  availability 
and  several  LCF  specific  performance  requirements,  the  ARPANET  was 
recommended  for  use  by  the  LCF. 

HARDWARE  AND  COMPUTER  SYSTEMS  REQUIRED 
TO  HOST  THE  LCF 

The  hardware  and  computer  systems  capable  of  hosting  the  LCF  were  examined 
in  detail.  Comparative  evaluations  of  the  DECSYSTEM-10,  UNIVAC  1108s 
and  a combination  of  the  H-6080  and  H-6180  RADC  systems  were  made.  Based 
on  computer  availability,  mass  storage,  costs,  support  software,  network  con- 
siderations, and  communication  requirements,  the  H-6080/H-6180  system 
offers  a number  of  significant  advantages  over  the  other  two  candidate  systems. 
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FORMAL  OPERATING  RULES  AND  PROCEDURES 

BETWEEN  THE  LCF  AND  HOL  USERS 
— 

Control  procedures  are  r^uired  for  the  following: 

• Software  error  processing 

• Software  change  processing 

• Software  release 

During  the  development  phase  of  the  language  and  compilers,  a Software  Prob- 
lem Report  (SPR)  is  used  to  report  errors.  During  the  operational  phase,  users 
communicate  th?ir  problems  electronically  to  the  LCF,  where  analysts  deter- 
mine whether  the  problem  is  an  error,  or  requires  a formal  change.  All  formal 
changes  are  requested  on  a standard  change  request  form  and  are  submitted  to 
a Configuration  Control  Board  (CCB)  for  review  and  processing.  System 
releases  during  development  are  relatively  informal;  however,  during  system 
operation  by  users,  release  procedures  must  be  strictly  controlled  for  content 
and  user. 

PERSONNEL  STAFFING  AT  THE  LCF 

Personnel  staffing  needs  for  the  LCF  were  examined  in  detail.  The  personnel 
qualifications  for  each  proposed  staff  member,  and  the  manpower  sources  of 
Air  Force,  civil  service  and  government  contractors,  from  which  the  person- 
nel staff  would  be  obtained,  were  evaluated.  A staffing  profile,  headed  by  a 
Civil  Service  Computer  Specialist  as  the  LCF  manager,  together  with  a primary 
mix  of  Air  Force  and  civil  service  personnel,  is  recommended. 

DESIGN  OF  THE  PHYSICAL  FACILITY 

The  LCF  design,  based  on  the  use  of  computer  terminals  rather  than  a total 
computer  system,  does  not  require  any  special  considerations  outside  of  the 
expected  air-conditioning,  power  maintenance  and  consumable  requirements. 
Parametric  cost  elements  were  developed  and  total  costs  for  the  facility  were 
estimated. 


1 


4 


The  basic  development  costs  of  the  LCF  for  controlling  a single  HOL  are 
estimated  at  169  to  275  man-months  plus  a fixed  fee  per  anticipated  user.  The 
addition  of  a second  HOL  would  add  122  to  218  man-months  to  the  development 
effort.  Monthly  operation  costs  for  a single  HOL  are  approximately  $14, 000  per 
month  with  a monthly  maintenance  cost  of  4 to  5 man-months.  Addition  of  a 
second  HOL  would  add  $3,000  to  the  monthly  operation  and  another  4 to  5 man- 
months  to  the  monthly  maintenance  cost. 

HOL  SOFTWARE  TOOLS 

Volume  2 of  the  report  deals  with  the  software  components  required  to  support 
the  LCF.  In  recent  years,  RADC  has  funded  several  programs  that  involved 
language  support  software  tools.  As  part  of  the  LCF  study,  CSC  examined  these 
tools  to  meet  two  requirements:  (1)  to  analyze  existing  tools  developed  under 
RADC's  sponsorship  and  (2)  to  make  recommendations  for  incorporating  these 
tools  into  an  LCF.  The  following  software  tools  were  analyzed  in  detail: 

• JOVIAL  Compiler  Implementation  Tool  (JOCIT) 

• JOVIAL  Language  Management  Tool  (JLMT) 

• JOVIAL  Compiler  Validation  System  (JCVS) 

• JOVIAL  Automated  Verification  System  (JAVS) 

• SEMANOL 

JOCIT,  which  is  aimed  at  providing  low  cost  and  efficient  JOVIAL  compilers  for 
the  J-3  language,  was  evaluated  to  be  a competent  and  serviceable  J-3  compiler 
tool  for  the  recommended  LCF  computer  configuration. 

Although  JLMT  succeeds  in  identifying  useful  categories  of  statistics  to  be 
gathered,  it  does  not  define  the  functional  specifications  for  a viable  system. 
However,  a language  measurement  tool  would  satisfy  a real  need  in  the  LCF. 

In  the  section  on  proposed  tools  for  the  LCF,  the  omissions  identified  within 
JLMT  are  addressed  and  corrections  are  suggested. 
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The  JOVIAL  Compiler  Validation  System  (JCVS)  which  has  been  implemented 
for  both  the  J-3  and  J73  Level  I languages  provides  a useful  base  from  which  to 
develop  validators  for  other  HOLs.  With  the  enhancements  identified,  JCVS 
could  provide  an  even  greater  basis  for  compiler  validation  in  an  LCF. 

The  JOVIAL  Automated  Verification  System  (JAVS),  implemented  for  J-3  users 
as  a companion  to  the  JOCIT  Compiler  under  the  HIS-6000  series,  was  evalu- 
ated to  be  a useful  companion  to  the  J-3  compiler.  The  JAVS  principles  and 
functional  design  also  may  be  applied  to  other  HOLs. 

SEMANOL  is  a programming  tool  that  allows  description  of  both  the  syntax  and  the 
semantics  of  an  HOL  as  a machine-verifiable  language  specification.  Within  the 
context  of  an  LCF  designed  to  support  existing  languages,  SEMANOL  was  judged 
to  be  largely  peripheral  to  the  central  tool  requirement. 

The  LCF  study  was  designed  to  be  comprehensive  in  nature.  Thus,  the  control 
of  a language  including  the  required  control  facility  is  described  in  Volume  1. 

A significant  amount  of  user  benefits,  in  terms  of  software  support  tools  other 
than  the  compilers  themselves,  is  described  in  Volume  2.  Therefore,  the 
reader's  interest  in  either  the  control  or  support  aspects  of  an  LCF  should  be 
used  to  dictate  volume  preference. 
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SECTION  1 - INTRODUCTION 


This  volume,  Volume  1,  provides  a detailed  evaluation  of  all  the  LCF  components 
(including  a discussion  of  multiple  HOLs  from  a single  LCF)  except  software; 
Volume  2 provides  a detailed  evaluation  of  the  software  tools  required  to  imple- 
ment, control,  and  maintain  the  HOL.  The  remainder  of  this  volume  is  organ- 
ized as  described  in  the  following  paragraphs. 

Section  2 addresses  the  data  communications  requirements  for  the  LCF.  Four 
potential  LCF  communications  configurations  are  defined  and  a response  time 
model  is  developed.  Using  the  model,  computer  simulations  are  performed  and 
an  optimum  communications  configuration  is  recommended. 

The  hardware  and  computer  systems  required  to  host  the  LCF  are  addressed  in 
Section  3.  This  consists  of  comparative  evaluations  of  three  large-scale  time- 
sharing computer  systems;  the  DECSYSTEM-10,  the  UNIVAC  1108s  (CSC's 
INFONET  System),  and  a combination  of  the  H-6080  and  H-6180  RADC  systems. 

The  operating  rules  and  procedures  required  for  the  LCF  are  defined  in  Section  4. 
This  includes  detailed  procedures  for  language  acceptance  testing,  problem 
reporting,  change  proposals,  and  change  control  and  implementation. 

The  personnel  staffing  requirements,  as  well  as  design  and  cost  of  the  physical 
facility,  are  addressed  in  Section  5.  An  LCF  organization  structure  and  the  job 
duties  and  personnel  qualifications  for  each  proposed  staff  position  are  defined, 
along  with  the  recommended  manpower  sources  for  each  position.  The  facility 
design  for  the  LCF  addresses:  the  equipment  definition;  facility  floorspace  and 
layout;  consumables;  maintenance;  and  air-conditioning  and  electrical  power 
requirements.  Finally,  parametric  cost  elements  are  developed  and  total  costs 
for  the  facility  are  estimated. 
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In  Section  6,  two  approaches  to  controlling  multiple  HOLs  are  discussed.  These 
approaches  are:  (1)  controlling  multiple  HOLs  from  a single  LCF  and  (2)  from 
multiple  LCFs.  Both  approaches  are  evaluated  and  the  considerations  of  added 
staffing,  facilities,  and  equipment  are  discussed. 
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SECTION  2 - COMMUNICATIONS  AND  NETWORK 
REQUIREMENTS 


This  section  addresses  two  separate  but  closely  related  topics:  the  communica- 
tions requirements  for  the  LCF,  and  the  network  applicability  to  the  LCF  require- 
ments. The  discussion  of  the  requirements  for  the  LCF  includes  the  definition 
of  alternative  communications  configurations,  and  the  formulation  and  exercising 
of  an  evaluation  model  to  determine  an  optimum  configuration.  The  network 
investigation  included  a survey  of  several  existing  telecommunications  networks. 

2.1  COMMUNICATIONS  REQUIREMENTS 

The  approach  taken  to  develop  the  LCF  communications  requirements  consisted 
of  several  steps.  First,  the  functional  objectives  for  the  communications  system 
were  developed.  Then,  alternative  communications  configurations  were  synthe- 
sized. Next,  the  operations  and  procedures  required  for  each  of  the  functional 
objectives  were  determined.  Following  this,  an  evaluation  model  was  formulated, 
and  performance  parameters  were  estimated  for  each  of  the  alternative  configu- 
rations. Using  the  input  parameters,  the  evaluation  model  was  then  exercised  in 
a simulation  to  determine  the  expected  performance  of  the  four  alternative  con- 
figurations. Finally,  the  results  of  the  simulation  exercise  were  evaluated  and 
an  optimum  communications  system  configuration  was  recommended. 

2.1.1  COMMUNICATION  SYSTEM  FUNCTIONAL  OBJECTIVES 

Based  on  the  LCF  system  requirements  and  objectives,  the  major  functions  of  the 
communication  system  are  to  provide  for: 

• User  problem  definition 

• Maintenance  of  HOLs  and  tools 

• Evaluation  of  language  utilization 

• Determination  of  nonstandard  compiler  versions 
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2. 1. 1. 1 User  Problem  Definition 


There  are  five  items  to  be  considered  in  defining  the  user  problem.  The  first  is 
to  identify  any  language  deficiency  in  generating  object  code  for  a particular  sub- 
set of  source  code.  Next  is  to  identify  any  problem  in  generating  object  code  that 
meets  the  design/performance  objective  of  a subset  of  source  code.  The  third  is 
to  identify  any  language  deficiency  in  addressing  a particular  functional  design  or 
performance  objective  without  the  need  for  use  of  machine  level  (assembly)  code. 
The  fourth  is  to  identify  any  problem  in  interfacing  subsets  of  code  written  in 
other  languages  for  specific  purposes  (such  as  higher  efficiency  or  to  take  advan- 
tage of  hardware-specific  features),  with  code  elements  written  in  the  HOL.  The 
final  item  is  to  identify  problems  in  understanding  a particular  HOL  feature  and 
its  application. 

2. 1.1. 2 Maintenance  of  HOLs  and  Tools 

Similarly,  there  are  five  items  in  this  area.  The  first  is  design  and  implemen- 
tation of  HOL  modifications.  Next  is  dissemination  of  HOL  modifications  to  the 
users.  The  third  is  the  implementation  and  integration  of  the  HOL  modifications 
into  the  user  system.  The  fourth  is  to  verify  that  proper  implementation  and 
integration  were  performed.  The  final  item  is  dissemination  of  information 
describing  the  HOL  modifications  to  the  users.  All  five  items  apply  to  both  main- 
tenance of  the  HOLs.  and  the  HOL  support  tools. 

2. 1.1.  3 Evaluation  of  Language  Utilization 

There  are  three  points  for  consideration  here.  First,  the  language  utilization 
data  must  be  collected  by  the  language  analyzer  operating  in  the  user's  compiler. 
Then,  the  collected  data  must  be  transmitted  to  the  LCF.  Finally,  the  data  must 
be  accumulated,  analyzed,  and  interpreted  at  the  LCF. 

2. 1.1.  4 Determination  of  Nonstandard  Compiler  Versions 

Six  points  are  considered  here.  First,  test  codes  must  be  generated.  Then,  the 
test  codes  must  be  transmitted  to  the  user.  Next,  the  user's  HOL  computer  must 


2-2 


r 


be  accessed  and  the  test  code  compiled.  Then,  the  results  of  the  compilation  must 
be  transmitted  back  to  the  LCF.  Finally,  the  data  must  be  evaluated  at  the  LCF 
and  a determination  must  be  made  of  the  deviations  in  the  user's  version  of  the 
compiler. 

Later  in  this  section,  the  detailed  objectives  identified  above  in  each  of  the  four 
areas  are  treated  in  one-to-one  correspondence  to  the  operations  and  procedures 
required  to  achieve  them. 

2.1.2  ALTERNATIVE  CONFIGURATIONS 

In  this  study,  the  following  alternative  communication  systems  were  hypothesized 
for  analysis: 


■ 


Manual  baseline  system 

Semi -automated  telecommunications  system 

Semi -automated  teleprocessing  system 

Automated  telecommunications  and  teleprocessing  system 


2. 1.2.1  Manual  Baseline  System 

The  manual  baseline  system  presupposes  no  telecommunication  links  between  the 
LCF  and  users'  facilities  other  than  ordinary  telephone  service.  LCF  user  inter- 
faces are  accomplished  by  basically  manual  methods.  Formal  data,  documenta- 
tion, and  other  material  exchanges  are  accomplished  by  mail  (or  courier).  To 
the  extent  possible,  documents  and  materials  are  in  machine-generated  and 
machine- readable  formats. 

2. 1.2. 2 Semi-Automated  Telecommunication  System 


The  semi-automated  telecommunication  system  configuration  is  local  terminal  to 
remote  terminal  and  assumes  ordinary  telephone  service  as  well  as  telecommuni- 
cation links  between  the  LCF  and  user  facilities,  but  not  between  LCF  computers 
and  user  computers.  Telecommunication  facilities  include  terminal  devices  and 
line  interface  equipment.  Terminal  devices  capable  of  accepting  or  producing 
machine-readable  inputs  such  as  cards,  paper  tape,  or  magnetic  tape  have  been 
assumed  to  exist. 
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Intercommunication  is  accomplished  by  a combination  of  manual  procedures  and 
terminal-to-terminal  data  transmission.  Formal  document  and  material  trans- 
mission using  terminal  devices  is  the  basic  means  for  information  and  data 
exchange  between  the  LCF  and  HOL  users.  Where  possible,  documents  and 
material  transmission  are  effected  in  machine -gene  rated  and  readable 
formats. 

2.  1.  2.  3 Semi-Automated  Teleprocessing  System 

The  third  configuration,  semi-automated  teleprocessing,  is  local  terminal  to 
remote  computer  and  assumes  that  ordinary  telephone  service  as  well  as  tele- 
communications links  exist  between  the  LCF  and  user  facilities,  but  not  directly 
between  the  LCF  and  user  computers.  The  telecommunications  facilities  include 
terminal  devices,  line  interface  equipment,  and  computer  interface  equipment. 
Terminal  devices  in  LCF  and/or  user  facilities  provide  remote  interface  to 
user  and/or  LCF  computers  with  teleprocessing  capabilities. 

LCF  user  interfaces  are  accomplished  by  a combination  of  manual  procedures  and 
automated  data  transmission  such  as  computer  to  terminal,  terminal  to  computer, 
and  terminal  to  computer  to  terminal.  Formal  data  transmission  via  terminal 
devices  and  terminal-computer  interfaces  is  employed  for  information  exchange 
between  LCF  and  HOL  users.  To  the  extent  possible,  data  transmission  from  the 
transmitting  facility  is  accomplished  by  direct  computer  entry  processing  and 
machine-generated  outputs  at  the  receiving  facility. 

2. 1.2. 4 Automated  Telecommunications  and  Teleprocessing  System 

Finally,  the  fourth  alternative  - an  automated  telecommunications  and  teleproc- 
essing system  - assumes  ordinary  telephone  service  as  well  as  telecommunica- 
tions links  between  the  LCF  and  user  computer  systems.  Telecommunications 
facilities  include  terminal  devices,  line  interface  equipment,  and  computer  inter- 
face equipment.  Terminal  devices  in  the  LCF  and/or  user  facilities  are  capable 
of  interface  with  their  own  computers  and  remote  interface  to  the  user  and  LCF 
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computers.  Additionally,  LCF  user  interfaces  are  accomplished  by  a combina- 
tion of  manual  and  semi -automated  data  entry  procedures  and  automated  data 
transmission  (i.e. , terminal  to  computer,  computer  to  computer,  and  computer 
to  terminal).  Formal  data  transmission  via  terminal-computer  and  computer- 
computer  interfaces  is  employed  for  information  exchange  and  interaction  between 
LCF  and  HOL  users.  To  the  extent  possible,  data  transmission  and  direct  inter- 
action between  the  LCF  and  user  computers  is  employed,  resulting  in  directly 
usable  machine-generated  outputs  at  the  LCF  and  user  facilities. 

2.1.3  SYSTEM  OPERATIONS  AND  PROCEDURES 

While  conducting  this  study,  detailed  operations  and  procedures,  as  applicable 
for  each  functional  objective,  were  determined  for  each  of  the  four  communica- 
tion system  configurations.  To  ensure  completeness,  the  form  shown  in  Fig- 
ure 2-1,  Communications  Operations  and  Procedures  Form,  was  used.  Com- 
pleted forms  reflecting  operations  and  procedures  for  each  system  objective  as 
implemented  in  each  of  the  alternative  communication  system  configurations  are 
contained  in  Appendix  A - Communications  Operations  and  Procedures. 

2.1.4  ALTERNATIVE  CONFIGURATIONS  EVALUATION  MODEL 

This  subsection  reports  the  results  of  quantitative  trade-offs  of  the  alternative 
communication  system  configurations.  An  evaluation  functional  model  of  the  LCF- 
user  communications  functions  was  developed;  this  model  is  described  and  the 
input  parameters  characterizing  performance  of  the  various  manual  and  automated 
links  in  the  four  configurations  are  determined  (or  estimated).  Using  the  input 
parameters,  the  evaluation  model  is  exercised  in  a simulation  to  determine  the 
expected  performance  of  the  configurations. 

2.1.5  FUNCTIONAL  MODEL 

Based  on  the  description  of  the  communication  system  configurations  and  the 
operational  procedures  outlined  in  this  section  and  described  in  Appendix  A,  a 
generalized  functional  model  was  developed.  The  model  was  used  during  the 
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Figure  2-1.  Communications  Operations  and  Procedures  Form  (1  of  4) 


Maintenance  of  HOLS  and  Tools  I System  Operation  & Procedures 


Figure  2-1.  Communications  Operations  and  Procedures  Form  (2  of  4) 


(A)  Collection  of  user  language  by  lan- 


Figure  2-1.  Communications  Operations  and  Procedures  Form  (3  of  4) 


Determination  of  Non-Standard 

Compiler  Versions  System  Operation  & Procedures 


Figure  2-1.  Communications  Operations  and  Procedures  Forms  (4  of  4) 


course  of  the  study  for  estimating  system  response  time  (turnaround)  time.  Fig- 
ure 2-2  depicts  this  generalized  functional  model.  In  this  figure,  rectangles 
represent  events  (stimulus/response  pairs)  while  connecting  lines  represent  func- 
tional arguments  that  may,  depending  on  the  alternative  configuration  .uer  con- 
sideration, be  implemented  in  different  ways. 

Table  2-1  summarizes  the  differences  in  implementation  of  the  four  configurations. 
Table  2-2  details  the  way  in  which  each  functional  argument  is  implemented  in 
each  of  the  four  configurations  under  consideration.  The  functional  model  devel- 
oped may  be  used  to  simulate  system  response  times  using  Monte  Carlo  tech- 
niques by  means  of  the  SOLVNET  program,  a general  purpose  program  applica- 
ble to  many  network  flow  problems.  In  the  LCF  application,  the  times  required 
to  execute  any  of  the  system  functional  arguments  shown  in  Figure  2-2  or 
Table  2-2  comprise  independent  performance  parameter  inputs.  It  was  assumed 
that  each  of  the  alternative  functional  arguments  is  statistically  independent. 

The  SOLVNET  program  was  operated  on  performance  parameter  inputs  (shown 
in  Table  2-3)  under  the  assumption  that  the  function  execution  times  are  random 
with  triangular  probability  density  functions.  The  minimum  time  estimate  is  the 
execution  time  that  is  considered  the  shortest  possible  (probability-of-execution 
in  less  than  the  minimum  time  equals  zero).  Likewise,  the  maximum  time  esti- 
mate is  considered  to  be  the  longest  possible  (probability-of-execution  in  longer 
than  the  maximum  time  equals  zero).  The  nominal  execution  time  corresponds 
to  the  mode  of  the  triangular  probability  density  function.  Accordingly,  the 
probability  density  at  the  nominal  execution  time  estimate  is  given  by  twice  the 
reciprocal  of  the  difference  between  the  maximum  and  minimum  estimates. 

The  SOLVNET  program  accepts  the  execution  time  estimates  for  the  functional 
arguments,  together  with  network  topology  and  modal  logic  operators,  and  by 
Monte  Carlo  techniques,  determines  the  mean,  standard  deviation,  and  mode  of 
the  distribution  of  system  response  time. 
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Figure  2-2.  LCF-Users'  Communication  Functional  Model 


Table  2 1.  Communication  System  Configurations 
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Table  2-2.  Specific  Functional  Implementations  (1  of  3) 
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Table  2-2.  Specific  Functional  Implementations  (3  of  3) 


Transmit  deviation  LCF  mail  to  LCF  terminal-to  LCF  terminal-to-  LCF  computer-to- 

notices  user  user  terminal  user  computer  user  computer 


Table  2-3.  Functional  Argument  Execution  Times  Estimates  (1  of  3) 
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♦Time  estimates  listed  are  minimum,  nominal  and  maximum. 


Table  2-3.  Functional  Argument  Execution  Times  Estimates  (2  of  3) 


♦Time  estimates  listed  are  minimum,  nominal  and  maximum. 


Table  2-3.  Functional  Argument  Execution  Times  Estimates  (3  of  3) 


*Time  estimates  listed  are  minimum,  nominal  and  maximum. 


2. 1.5.1  Input  Parameters 


Input  parameters  for  the  functional  model  consist  of  estimates  of  execution  times 
for  the  various  functional  arguments  as  implemented  in  the  four  configurations. 
These  estimates  (based  on  a consensus  of  experience)  are  shown  in  Table  2-3, 
Functional  Argument  Execution  Times  Estimates. 

2. 1.5.  2 Quantitative  Evaluation 

The  input  parameter  estimates  were  used  in  the  SOLVNET  model  to  simulate 
system  response  times  for  both  the  Problem  Occurrence -Receipt  of  Verification 
Message  throughput  thread  and  the  User  Operations-Language  Deviations  Thread. 
These  threads  are  called  problems  and  statistics,  respectively.  The  problem 
thread  has  two  cases:  A-D  problems  and  E problems.  E problems,  to  be 
handled  by  telephone,  are  expected  to  require  only  a few  minutes  to  a few  hours 
for  reconciliation,  so  they  were  not  simulated  by  SOLVNET.  Table  2-4  summa- 
rizes the  results  of  both  the  A-D  problems  thread  and  the  statistics  threads. 

2.1.6  CONCLUSIONS  AND  RECOMMENDATIONS 

Certain  conclusions  are  evident  in  Table  2-4.  First,  a problem  system  response 
time  for  the  manual  baseline  configuration  is  more  than  twice  that  of  the  auto- 
mated configurations;  that  is,  about  nine  days  for  manual  as  compared  to  about 
four  days  for  the  automated  configurations.  Likewise,  language  statistics 
response  time  for  the  manual  configuration  is  more  than  twice  those  for  auto- 
mated configurations  - seven  days  versus  three  days.  Inasmuch  as  the  standard 
deviations  are  approximately  the  same  for  every  configuration,  no  distributions 
can  be  made  on  that  basis. 

Experience  with  similar  information  storage  and  retrieval  systems  suggests  that 
the  value  (or  utility)  of  information  depends  mainly  on  the  type  of  application  and 
timeliness.  Generally,  expected  voluntary  utilization  can  be  expected  to  increase 
as  response  time  decreases.  Accordingly,  nine  days  is  too  long  a time  to  ensure 
adequate  user  participation  to  justify  the  system;  hence,  the  manual  baseline  con- 
figuration is  not  recommended.  Inasmuch  as  response  times  are  approximately 
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the  same  for  all  three  automatic  configurations,  the  choice  of  automation  is  not 
dictated  by  a response  time  rationale.  Rather,  based  on  the  relative  costs  for 
the  approximately  equivalent  semi-automated  telecommunication  and  semi- 
automated  teleprocessing  systems,  as  contrasted  with  the  substantially  higher 
fully  automated  configuration  costs,  the  semi -automated  teleprocessing  system 
is  recommended. 

2.2  NETWORK  APPLICABILITY 

In  developing  the  performance  requirements  for  computer  communication  net- 
works, three  general  considerations  apply.  First,  computer-to-computer  or 
terminal-to-computer  communications  network  requires  a burst  transmission 
rate  several  orders  of  magnitude  higher  than  average  rates.  Statistics  on  tele- 
typewriters, graphic  consoles,  and  batch  terminals  show  that  the  ratio  of  burst 
rate  to  average  rate  is  approximately  100  to  1.  This  indicates  that  if  a standard 

communications  line  is  established  for  a computer  conversation,  the  average 

i 

utilization  of  that  line  will  be  only  about  1 percent,  and  therefore  the  cost  will  be 
10  to  100  times  higher  than  the  cost  of  moving  the  data  bits. 

The  second  consideration  is  that  the  connect  time  (time  required  to  initially 
establish  a communications  link)  must  be  short  enough  that  the  computer  or  com- 
puter users  are  not  delayed  unduly.  An  acceptable  connect  time  for  computers 
is  less  than  one  second  as  opposed  to  20  or  30  seconds  for  voice  communications. 

The  final  general  consideration  is  that  the  error  rate  for  intercomputer  traffic 
must  be  far  lower  than  that  required  for  voice  communications,  since  there  is 
usually  little  redundancy  in  the  system.  At  the  same  time,  the  reliability  or 
uptime  of  the  data  communications  system  must  be  high  enough  to  ensure  the 
resource  availability  to  the  remote  user. 

Few  communication  systems  exist  that  possess  the  characteristics  just  described. 
One  innovative  and  state-of-the-art  communications  system  that  does  possess 
these  characteristics  is  the  ARPA  Network  (ARPANET),  which  is  described  later. 
Prior  to  the  discussion  of  ARPANET,  three  other  communications  networks  are 
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discussed  for  applicability  to  the  LCF  communications  requirements:  AUTOVON, 
AUTODIN,  and  a common  carrier-based  network. 

2.2.1  AUTOVON 

AUTOVON  is  essentially  not  applicable  to  the  requirements  of  the  LCF  user  com- 
munications interface.  This  conclusion  is  based  on  the  procedural  constraints  on 
use  of  system  facilities  rather  than  on  inability  to  meet  the  technical  requirements. 

AUTOVON  is  basically  intended  for  voice  rather  than  data  communications  or 
interoperation  of  data  processing  equipment.  AUTOVON  access  is  not  available 
to  Government  contractors  without  special  approval  by  DCA.  Furthermore,  with- 
out special  approval  by  DCA,  the  constraints  on  use  of  AUTOVON  for  data  oper- 
ations include: 

• Limit  on  circuit-holding  (continuous  interconnect)  time  on  a single 
subscriber  line  of  up  to  15  minutes  at  any  time  during  the  working 
day;  no  limit  after  the  working  day  (7  a.  m.  to  5 p.m.  in  each  time 
zone) 

• Total  allowable  holding  time  for  all  connections  in  a working  day 
limited  to  one  hour  (e.g.  , four  15-minute  periods) 

• User  must  disconnect  after  one  minute  without  data  criteria 

• User  terminal  equipment  must  have  built-in  features  that  auto- 
matically apply  15-minute  holding  time  and  one  minute  without 
data  criteria  to  truncate  connection 

It  is  not  likely  that  DCA  would  find  the  objectives  of  the  LCF  in  keeping  with  the 
intended  purposes  of  AUTOVON,  or  important  enough  to  grant  special  exceptions 
to  the  above  constraints. 

2.2.2  AUTODIN 

AUTODIN  is  applicable  only  to  certain  of  the  operations  described  in  the  three 
automated  communications  interface  system  definitions.  These  would  be 
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operations  or  functions  for  which  direct  and  continuous  connection  is  not  required 
and  for  which  time  delays  in  data  transmission  are  not  critical. 

AUTODIN  is  basically  a store-and-forward  message-switching  system.  There 
is  no  guarantee  of  immediate  connection  between  transmitter  and  receiver  facil- 
ities for  data  transmission.  Transmission  during  the  same  day  is  guaranteed, 
however.  The  usual  maximum  delay  between  data  input  and  reception  at  designee 
is  about  two  hours.  Thus,  AUTODIN  might  only  be  applicable  to  the  semi- 
automated  telecommunications  LCF  system. 

Contractors  can  have  access  to  the  network.  However,  all  communications  line 
installations  must  be  permanent.  In  addition,  the  LCF  and  user  computers  must 
be  programmed,  or  terminals  designed  (or  programmed)  for  the  AUTODIN  pro- 
tocols. Thus,  AUTODIN  would  be  costly  for  use  where  the  number  of  HOL  users 
is  large. 

In  general,  AUTODIN  does  not  appear  to  be  a practical  choice  for  communica- 
tions interface  between  LCF  and  users,  because  of  the  above  limitations. 

2.  2.3  COMMON  CARRIER-BASED  COMMUNICATIONS  NETWORK 

It  would  be  possible  to  design  and  implement  a communications  network  to  meet 
the  LCF  requirements  and/or  desired  capabilities  based  on  use  of  common  car- 
rier network  facilities.  However,  any  automatic  call-direct  access  capabilities 
would  have  to  be  implemented  as  interface  equipment  at  LCF  or  user  facilities. 

In  addition,  there  would  definitely  be  a need  for  specific  engineering  effort  to 
design  the  total  network,  procure  the  interface  equipment  and  terminals  with  any 
special  features,  and  install  the  interface  equipment. 

Where  there  are  likely  to  be  a large  number  of  users  who  may  leave  or  enter  the 
system  at  any  time  (e.g. , contractor  dropout  when  project  is  completed),  engi- 
neering installation  and  removal  of  appropriate  interface  equipment  would  be 
difficult  and  costly  to  administer.  Also,  when  classified  software  is  being  devel- 
oped by  a user,  this  network  could  not  be  employed  for  transmissions  of  any 
related  data. 
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Because  of  these  deficiencies,  use  of  an  existing  DOD  communications  network 
should  be  considered  before  a common  carrier-based  communications  network. 

2.2.4  ARPANET 

The  ARPANET  is  applicable  to  all  of  the  LCF  communications  requirements. 

This  network  creates  a switched  network  out  of  full-period  leased  lines  by  insert- 
ing switching  computers  at  appropriate  nodes.  The  data  transmitted  between  the 
computers  is  divided  into  fixed-length  packets  whose  length  is  not  in  any  way 
connected  with  the  message  control.  A packet  length  is  1000  bits  and  the  packets 
are  treated  as  independent  data  blocks  to  be  sent  over  whatever  path  happens  to 
be  free  at  the  moment.  At  the  destination,  the  packets  are  reassembled  in  the 
proper  order  and  forwarded  to  the  receiving  computer. 

The  interface  with  the  network  is  accomplished  via  an  Intermediate  Message 
Processor  (IMP)  for  interfacing  a computer,  or  a Terminal  Interface  Processor 
(TIP)  for  interfacing  both  computers  and  terminals.  Each  IMP  or  TIP  has  at 
least  two  connections  to  other  IMPs  or  TIPs,  and  some  have  as  many  as  three 
or  four.  A message  from  one  computer  to  another  is  not  necessarily  all  trans- 
mitted on  the  same  lines.  This  is  accomplished  by  the  packet-switching  concept 
mentioned  above,  and  allows  the  network  to  use  all  of  its  communications  lines 
more  efficiently.  (The  technical  and  cost  considerations  of  interfacing  the  LCF 
terminals  with  ARPANET  are  discussed  in  Section  3 of  this  volume. ) 

IMPs  or  TIPs  are  located  throughout  the  nation,  and  terminals  can  be  directly 
interfaced  with  a TIP  by  plug  connection  or  by  the  use  of  modems.  ARPANET 
host  computers  employ  standard  ARPANET  protocols  that  are  currently  available 
for  most  large-scale  timesharing  computers.  Often,  the  only  software  requiring 
modification  is  the  user's  executive  software  (to  interface  the  standard  ARPANET 
protocol  package). 

General  performance  of  the  ARPANET  system  is  exemplified  by  its  capability 
to  deliver  short  messages  anywhere  in  the  country  in  0.  1 second  and  by  permitting 
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throughput  rates  of  up  to  80  kilobits  per  second  on  long  messages.  Direct  con- 
nection of  up  to  64  consoles  and  peripheral  devices  to  a single  TIP  providing 
intercommunication  with  remote  hosts  (computers  or  terminals)  at  rates  of  up 
to  20  kilobits  per  second  is  also  possible. 

The  single  drawback  found  with  this  network  is  that  it  is  not  secure.  However, 
this  fact  is  not  considered  in  itself  to  be  a critical  constraint,  as  problems  involv- 
ing classified  code  represent  only  a very  small  portion  of  all  problems  encoun- 
tered with  a HOL.  Classified  code,  when  encountered,  can  be  handled  by  secure 
manual  procedures. 

The  preceding  discussion  indicates  that  ARPANET  is  indeed  applicable  to  the 
LCF  communications  requirements.  CSC  recommends  this  network  for  imple- 
mentation of  the  LCF. 
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SECTION  3 - HARDWARE  AND  COMPUTER  SYSTEMS 


This  section  defines  the  characteristics  of  the  hardware  necessary  to  support  the 
LCF  mission,  objectives,  and  software  tools.  LCF  system  requirements  are 
identified,  and  selection  of  candidate  host  computer  systems  is  discussed.  Next, 
detailed  evaluations  are  made  of  each  candidate  host  against  the  LCF  require- 
ments. Lastly,  the  candidate  hosts  are  evaluated  comparatively,  and  feasible 
cost-effective  hardware  is  recommended  for  LCF  implementation. 

3.1  STUDY  APPROACH 

The  hardware  surveyed  in  this  study  includes  various  types  of  terminal  devices 
(teletypewriter,  display,  batch,  and  intelligent  terminals)  as  well  as  three  can- 
didate host  computer  systems.  The  computer  systems  are: 

• UNIVAC  1108s  (CSC's  INFONET  System) 

• DECSYSTEM-10 

• Combination  of  Honeywell  6080  and  6180  systems  (RADC  Configuration) 
In  evaluating  these  systems,  the  following  assumptions  were  made: 

• Computer  time  on  all  of  the  host  computers  is  equally  available 

• Sufficient  mass  storage  for  LCF  pe.  nanent  files  is  available  in  each 

system 

• Costs  for  computer  time  on  the  host  computers  were  considered  sub- 
ject to  change  and  were  therefore  not  compared;  should  implementa- 
tion of  an  LCF  be  undertaken  by  RADC,  these  cost  factors  can  be 
added  to  the  computer  system  weighting  matrix  provided  in  this 
section 

3.1.1  METHODOLOGY 

The  methodology  used  in  performing  this  hardware  study  is  depicted  in  Figure  3-1. 
The  initial  function  of  this  study  was  to  identify  the  system  data  processing 
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requirements  for  each  of  the  LCF  configurations  recommended  in  Section  2. 
Based  on  the  identified  requirements,  three  candidate  host  computer  systems 
were  selected.  Following  this  selection,  each  of  the  candidate  systems  was 
evaluated  against  the  LCF  requirements.  Next,  comparative  evaluation  of  the 
three  candidates  was  performed,  and  hardware  recommendations  for  a cost- 
effective  LCF  system  implementation  were  made. 

3.1.2  LCF  COMMUNICATIONS  CONFIGURATIONS 


Of  the  four  communication  configurations  discussed  in  Section  2,  the  manual  and 
fully  automated  were  rejected  as  least  desirable.  Of  the  two  semi-automated 
configurations  remaining,  the  teleprocessing  configuration  was  recommended. 
Accordingly,  this  configuration  was  examined  to  determine  the  system  data 
processing  requirements  for  it.  An  identification  of  these  requirements  follows. 

3.1.3  LCF  SYSTEM  DATA  PROCESSING  REQUIREMENTS 

The  data  processing  requirements  for  the  selected  LCF  configurations  can  be 
categorized  as  follows: 

• Storage  requirements 

• Communications  requirements 

• Support  software  requirements 

• Host  computer  operating  environment 

Cost  evaluations,  required  to  ensure  the  cost-effectiveness  of  the  recommended 
LCF  hardware  and  computer  system,  are  provided  in  this  section.  These  evalu- 
ations consist  of  cost  estimates  for  the  new  hardware  and  new  software  associ- 
ated with  each  of  the  three  candidate  host  systems. 

3. 1.3.1  Storage  Requirements 

Storage  requirements  for  LCF  data  files  have  two  major  aspects.  The  first 
involves  the  mass  storage  requirement  for  permanent  LCF  files.  This  require- 
ment can  be  assumed  to  be  satisfied  by  the  extremely  large  storage  hardware 
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resources  of  each  of  the  candidate  timesharing  systems.  The  second  aspect  of 
LCF  data  storage  is  the  user  file  protection  required  to  provide  security  for  LCF 
permanent  data  files. 

3. 1.3.  2 Communications  Requirements 

Communications  requirements  also  consist  of  two  categories  or  types  of  require- 
ments. The  first  is  the  hardware  user  interface.  This  will  consist  of  data 
terminals  that  are  plug-compatible  with  the  hosts  and/or  the  recommended  com- 
munications network  (ARPANET).  The  second  type  of  communications  require- 
ment involves  interconnection  of  the  host  with  the  ARPANET. 

3. 1.3.  3 Support  Software  Requirements 

Support  software  requirements  for  the  LCF  can  be  focused  on  three  areas  of 
software.  The  first  of  these  is  the  user  interface  command  language  provided 
by  the  host  computer  operating  system.  The  second  is  the  file  management 
capabilities  of  the  operating  system.  And  the  third  is  the  implementation  of,  or 
the  feasibility  of  the  implementation  of,  the  LCF  software  tools  on  the  host 
computer. 

3. 1.3.  4 Host  Computer  Operating  Environment 

The  operating  environment  required  for  LCF  data  processing  includes  both  local 
and  remote  conversational  terminal  processing,  local  batch  processing,  and 
timesharing  of  CPU  time. 

3.1.4  LCF  CANDIDATE  SYSTEMS 

Candidate  selection  was  performed  based  upon  the  LCF  system  requirements 
.'dentified  above,  plus  the  additional  criteria  of  system  availability  and  use  of 
existing  Air  Force-owned  computer  hardware.  Treating  the  LCF  system  require- 
ments as  quantitative  criteria  and  the  two  additional  criteria  as  qualitative,  CSC 
selected  three  candidates.  The  candidates  are:  UNIVAC  1108s  (CSC's  INFONET 
System),  DECSYSTEM-10,  and  a combination  of  the  H-6080  and  H-6180  systems. 


3-4 


r 

| Examination  of  these  three  candidates  has  shown  that  each  meets,  or  can  be 

feasibly  modified  to  meet,  the  critical  data  processing  requirements  for  an  LCF 
system.  However,  the  cost  of  implementing  these  systems  was  found  to  vary 
significantly. 

3.2  DETAILED  REQUIRE  ME  NTS 

Each  of  the  candidate  systems  was  individually  evaluated  and  judged  against  each 
of  the  LCF  system  requirements.  The  merits  and  demerits  of  each  system  are 
described  in  terms  of  the  implementation  of  file  protection,  terminal  devices, 
telecommunications  interface,  support  software,  operating  environment,  and 
new  hardware  and  software  costs. 

3.2.1  STORAGE -FILE  PROTECTION 

3. 2. 1.1  INFONET  1108s 

In  the  INFONET  system,  file  protection  is  provided  at  three  levels:  system 
access,  data  access,  and  data  protection.  System  access  involves  establish- 
ment of  unique  library  and  file  identifiers  by  computer  center  personnel  working 
with  the  users.  Data  access  is  provided  by  operating  system  attachment  of  the 
file  identifier  and  file  access  attribute  data  (generated  by  the  creating  user  and 
the  system)  to  the  physical  file  and  library.  Both  private  and  shared  usage  are 
accommodated  via  the  access  attributes.  Types  of  access  provided  include 
unrestricted,  restricted  (add,  update  new  file,  execute),  and  read  only.  The 
third  level  of  file  protection  is  data  protection.  This  protection  consists  of 
hardware  and  software  features  that  prevent  direct  addressing  of  the  data  on  any 
storage  medium,  and  requires  that  the  data  be  indirectly  addressed  by  file  name. 
Data  protection  also  is  provided  against  loss  caused  by  hardware  malfunctions 
through  parity  checking,  program  checksumming,  and  file  logging  to  provide 
backup. 
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3. 2. 1.2  DECSYSTEM-1Q 


File  protection  in  the  DECSYSTEM-10  is  similar  to  that  implemented  in  the 
INFONET  system,  in  that  file  attributes  are  declared  by  the  creating  user  (and 
the  system)  and  are  attached  to  the  user  file  by  the  operating  system.  The 
standard  read  or  modify  privileges  are  provided  the  author  and  multiple  users 
by  the  file  attributes.  File  addressing  is  by  file  name  only.  A significant  posi- 
tive feature  of  the  DECSYSTEM-10  file  protection  mechanism,  which  is  not 
conventional,  is  that  of  providing  three  classes  of  file  protection  to  three  dif- 
ferent types  of  users:  (1)  author  of  file,  (2)  users  with  a common  project  num- 
ber, and  (3)  all  users. 

3. 2. 1.3  H-6080  GC OS 

File  protection  in  the  GCOS  system  is  a function  of  the  File  Management  Super- 
visor (FMS)  software  and  Base  Address  Register  (BAR)  addressing  in  the  slave 
processors.  FMS  is  a hierarchical  file  (or  catalog)  data  structure  that  dynami- 
cally assigns  permanent  files  to  storage  devices,  and  protects  file  access.  The 
protection  mechanism  consists  of  multiple  levels  of  control,  as  follows.  No  user 
can  address  a cataloged  permanent  file  except  through  FMS,  and  user  validation 
name  and  password  (attribute)  procedures  are  dynamically  created  and  imple- 
mented by  FMS.  Privileged  shared  access  of  files  also  is  provided.  Privileges 
include  read  only,  read  and  write,  purge,  modify  catalog,  lock  and  unlock,  and 
other  specialized  options.  And  by  user  option,  all  file  access  attempts  (invalid 
as  well  as  valid  accesses)  can  be  recorded  for  any  permanent  file.  And  finally, 
permanent  files  residing  on  shared  storage  devices  are  protected  by  a lock  byte, 
to  prevent  erroneous  updating  that  otherwise  would  be  possible  through  multiple 
user  accesses. 

3.  2. 1.4  H-6180  MULTICS 

File  protection  implementation  in  the  MULTICS  system  represents  the  current 
state-of-the-art,  and  it  is  accomplished  by  file  access  control  lists  and  by  eight 
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levels  of  software  and  hardware  privileged  file  access.  Data  and  instruction 
connectivity  in  the  "on-demand  paged”  address  space  (i.e. , total  main  memory 
plus  mass  storage)  of  the  MULTICS  virtual  memory  and  storage  system  is 
accomplished  by  segmentation.  All  information  in  the  system  is  organized  into 
hierarchical  trees  composed  of  segments.  There  are  two  types  of  segments: 

(1)  directory  segments  and  (2)  nondirectory  segments.  Associated  with  each 
segment  is  an  access  control  list  that  contains  the  access  attributes  for  the  seg- 
ment. The  access  attributes  are  status,  modify,  append,  and  null  (no  access) 
for  directory  segments,  and  read,  write,  execute,  and  null  for  nondirectory 
segments. 

In  addition  to  the  access  control  lists,  there  is  another  more  precise  file  pro- 
tection mechanism  provided  in  the  MULTICS  system.  This  is  ring  protection. 

It  consists  of  system  and  user  structuring  of  all  information  (data  and  instruc- 
tions) into  eight  concentric  ring  domains.  The  rings  are  numbered  0 through  7 
with  Ring  0 being  the  most  privileged  domain  and  Ring  7 the  least  privileged. 
Ring  protection  differs  from  conventional  file  protection  mechanisms  in  that 
instead  of  the  usual  two  levels  of  protection,  there  are  eight.  In  this  structure, 
intra-ring  access  and  lower-to-higher  ring  access  require  only  that  proper 
access  control  list  name  inclusion  be  provided.  However,  higher -to-lower  ring 
access  also  requires  the  use  of  a program  gate  that  must  be  supplied  by  the 

1 

owner  of  the  lower  ring  segment.  This  mechanism  offers  the  maximum  flexi- 
bility to  both  system  and  user  software  by  providing  a large  number  of  security 
levels  to  each  - three  levels  to  system  software  and  five  levels  to  user  software. 

A summary  of  the  file  protection  features  provided  by  each  of  the  candidate  sys- 
tems is  depicted  in  Table  3-1. 
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Table  3-1.  Candidate  System  File  Protection  Features 


^\Ilequire- 

v^ments 

System 

File 

Name 

Addressing 

Shared 

Access 

Attributes 

Multiple 
Classes 
of  Users 

Access 

Recording 

Multiple 

Levels 

UNIVAC  1108 

X 

X 

DECSYSTEM-10 

X 

X 

X 

H-6080 

X 

X 

X 

H-6180 

X 

X 

X 

X 

3.2.2  TERMINAL  DEVICES 


Terminal  devices  fall  into  four  categories  of  terminals:  (1)  teletypewriter, 

(2)  display,  (3)  batch,  and  (4)  minicomputer.  In  general,  equipment  costs 
increase  in  the  same  order  in  which  the  categories  above  are  numbered  (i.  e. , 
teletypewriter  costs  least;  minicomputer  costs  most).  Typical  equipment  cost 
ranges  for  each  category  are: 


Device  Category 


Typical  Cost 


Teletypewriter 

Display 

Batch 

Minicomputer 


$1,500  to  $7,500 
$5,000  to  $22,500 
$10, 000  to  $60, 000 
$35,000  to  $150,000 


From  these  gross  cost  comparisons,  it  is  easily  seen  that  the  teletypewriter 
terminal  holds  a distinct  advantage  in  cost.  In  addition  to  cost,  the  other  factors 
that  must  be  considered  in  selecting  terminal  equipment  are:  reliability,  editing 
and  formatting  capabilities,  operating  speeds,  and  input/output  medium.  With 
all  of  these  factors  considered,  the  terminal  equipment  was  examined  in  terms 
of  the  terminal  data  entry/output  requirements  for  the  LCF. 


1 
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ARPANET,  with  its  powerful  protocols  for  remote  terminal  processing  and  data 
file  transfer,  considerably  reduces  the  problem  of  terminal  selection.  Using 
ARPANET  and  the  TELENET,  LINK,  MAIL,  and  FILE  TRANSFER  protocols, 
the  LCF  (and  users)  terminals  are  required  to  perform  only  the  following  types 
of  message  communications: 

• Execution  control  of  remote  programs 

• Execution  control  of  local  programs 

• Data  entry  for  remote  programs 

• Print  nominal  volume  message  data 

• Initiation  of  local  data  file  transfer 

Collectively,  these  communications  messages  do  not  constitute  high  volume 
input/output,  as  a number  of  them  consist  of  conversational  command  and  control 
messages  only.  Further,  the  criticality  of  these  message  communications  can 
be  considered  low,  because  the  functions  of  the  LCF  are  not  performed  in  real 
time. 

Therefore,  two  conclusions  follow: 

• The  need  for  a minicomputer  to  handle  the  communications  control 
function  is  obviated  by  the  scope  and  power  of  the  ARPANET  protocols 

• The  need  or  convenience  of  the  better  editing  and  formatting  features 
provided  in  a display  terminal  is  difficult  to  justify  because  of  the 
relatively  small  number  of  message  types,  the  off-line  environment, 
and  the  additional  costs 

With  these  considerations,  the  choice  of  terminal  types  focuses  on  the  batch  or 
teletypewriter  terminal. 


L 
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message  data  to  be  communicated  between  the  LCF  and  the  users  appears  to  be 
of  two  distinct  types.  The  first  type  is  a set  of  conversational  messages  as 
shown  below: 


Message  Type 

Originating  With 

Communicating  With 

Local  program  execution 
control  - for  compiler 
validation  and  language 
statistics  analysis 

LCF  Terminal 

LCF  Host 

Remote  program  execution 
control  - for  compiler 
validation 

LCF  Terminal 

User  Host 

Software  problem  reports 

User  Terminal 

LCF  Terminal 

Language  compiler  change 
proposal 

User  Terminal 

LCF  Terminal 

Remote  data  entry  - for 
input  of  language  statistics 

User  Terminal 

LCF  Host 

Language  status  queries 

User  Terminal 

LCF  Host 

Considering  the  off-line  environment  of  the  LCF,  a teletypewriter  terminal  offers 
adequate  reliability,  editing  and  formatting,  operating  speed,  and  I/O  medium 
for  these  messages. 

A second  type  of  data  that  must  be  communicated  between  the  LCF  and  the  users 
consists  of  the  following  higher  volume  messages: 

• Software  problem  report  data  package 

• Compiler  modifications 

• Compiler  test  data 

• Language  status 

Because  of  its  larger  volume,  this  message  data  indicates  the  need  for  an  I/O 
medium  other  than  a teletypewriter.  The  more  desirable  I/O  media  would  be: 
card  reader  and  magnetic  tape  for  input;  card  punch,  magnetic  tape,  and  line 
printer  for  output. 
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Based  on  these, requirements,  the  optimum  terminal  device  is  seen  to  incorporate 
features  of  both  batch  and  teletypewriter  terminals  (i.  e. , interactive  keyboard, 
card  read/punch,  magnetic  tape,  and  line  printing). 

An  obvious,  although  expensive,  approach  to  providing  these  features  is  a full 
capability  minicomputer.  A second  and  significantly  more  economical  approach 
is  to  use  two  terminals:  a teletypewriter  terminal  for  the  conversational  mode 
requirement;  and  a low-speed,  low-volume*  batch  terminal  for  the  higher-volume 
data  communications.  Unfortunately,  neither  of  these  approaches  can  be  easily 
nor  economically  implemented  using  the  ARPANET,  which  does  not  directly 
support  batch  terminals  incorporating  a synchronous  device.  (Two  batch  options 
were  available  in  the  past  on  ARPANET  - (1)  a remote  job  minihost  option  and 
(2)  a magnetic  tape  option  - but  both  options  have  been  discontinued. ) 

Another  consideration,  however,  is  that  the  local  host  computer  (e.  g. , H-6180) 
could  be  used  to  interface  the  LCF  batch  terminal  with  the  ARPANET  TIP,  but 
this  consideration,  while  providing  batch  processing  at  the  LCF,  does  not  in  itself 
provide  the  user  with  a batch  medium. 

A third  approach  offers  feasible  and  economical  implementation  of  the  required 
features  for  both  the  LCF  and  the  user.  This  approach  is  a variation  of  the 
second  approach  in  that  it  involves  implementing  a teletypewriter  terminal  for  the 
conversational  mode  requirement,  plus  the  use  of  the  previously-mentioned 
ARPANET  protocols  implemented  in  a local  host  computer  (i.e.  , H-6180  and 
the  user  host)  for  the  higher  volume  data  communications. 

Considering  the  significant  implementation  cost  differentials,  the  third  approach 
is  the  approach  which  CSC  recommends.  It  is  further  recommended  that  two 
teletypewriter  terminals  be  used  in  the  LCF:  one  terminal  to  communicate  with 
the  users  through  the  MULTICS  system  and  the  ARPANET  TIP,  the  other  to 
communicate  with  the  LCF  software  tools  residing  in  the  GCOS  system. 
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The  model  of  teletypewriter  terminal  recommended  for  the  LCF  (two  terminals) 
and  for  the  users  (one  terminal  per  user)  is  a GE  TERMINET-300  (or  equivalent). 
The  characteristics  of  this  teletypewriter  terminal  are  shown  in  Table  3-2,  and 
the  rationale  for  its  selection  is  based  on  the  following  features. 

• Ease  of  use 

• Hardware  reliability  and  maintenance  availability 

• 30  cps  printer  speed 

• 96  print/128  keyboard  ASCII  character  set  offered 

• Unattended  data  entry  via  punched  paper  tape  and  computer  polling 

• Communications  interface  compatibility  (RS  232C)  with  most  large- 
scale  timesharing  systems  and  with  the  ARPANET  TIP 

3.2.3  TELECOMMUNICATIONS  NETWORK  INTERFACE 

This  requirement  has  been  qualified  further  by  the  recommendation  of  the 
ARPANET  in  Section  2,  since  only  the  DECSYSTEM-10  and  H-6180  are  availa- 
ble on  this  network. 

3.2.4  USER  INTERFACE  SUPPORT  SOFTWARE 
3. 2. 4.1  INFONET -1108s 

The  General  Programming  Subsystem  (GPS)  of  the  INFONET  System  provides 
a diverse  set  of  command  functions  to  the  user.  These  functions  can  be  grouped 
into  eight  major  command  groups: 

• Session  control  and  inquiry  (interactive  or  batch) 

• Program  construction  and  control 

• File  and  library  management 

• File  editing 
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• Program  checkout 


• Batch  management  (and  unit  record  output  formatting) 

• Control  terminal  management  (declare  terminal  characteristics) 

• Command  programming  (insert,  qualify,  and  delete  commands  from 
the  control  stream) 

Collectively,  these  commands  provide  a flexible  user  control  interface  to  a large 
remote  user  community.  They  also  are  supported  by  a common  diagnostic  facil- 
ity, which  provides  either  abbreviated  or  detailed  (at  user  option)  error  messages 
containing  associated  error  severity-level  indicators. 


Table  3-2.  Characteristics  and  Capabilities  of  the  GE  TERMINET-300 


COMPATIBILITY 

Teletype 

Yes 

IBM  2740 

No 

MODEL  CONFIGURATION 

KSR 

Yes 

ASR 

Yes 

FEATURES 

Parity  Checking 

Optional 

Parity  Generating 

Standard 

Polling/ Addressing 

Optional 

Automatic  Answer 

Optional 

PRINTER 

Rate  (Char/Sec) 

30 

Character  Set 

96  ASCII;  others 

KEYBOARD 

Character  Set 

128  ASCII 

TRANSMISSION 

Mode 

Half/Full  Duplex 

Speed  (bits/sec) 

110/150/300 

Code 

8-Level  ASCII 

Communications  Interface 

RS  232C  or  20  ma  DC 

Integral  Modem 

Optional 

Telephone  Coupler 

Optional 

PRICING 

Lease  (1  year) 

$105-$237 

Purchase 

$3,170  to  $6,610 
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3. 2. 4.2  DECSYSTEM-10 


DECSYSTEM-10  provides  some  features  not  found  in  the  INFONET  system,  in 
that  its  command  language  is  designed  to  optimize  service  to  both  local  and 
remote  users.  These  features  include: 

• More  extensive  file  manipulation  commands  (particularly  for  source 
files) 

• Terminal-to-terminal  communications 

• Multiple  job  control  commands 

• Commands  allowing  terminal  disconnect  and  subsequent  job  resump- 
tion at  point  of  disconnect  (functionally,  a session  termination 
snapshot/reload  capability) 

3. 2. 4.3  H-6080  GCOS 

The  common  language  of  the  GCOS  system  provides  a diverse  and  flexible  set  of 
commands  to  a local  user  community,  and  through  the  application  of  a front-end 
communications  processor,  these  commands  also  are  available  to  remote  users. 
The  commands  feature: 

• Interactive  terminal  and  batch  job  control 

• Direct  program  access  (from  interactive  terminal)  to  batch  jobs 

• Language  translators,  compilers,  and  assemblers 

• File  and  catalog  management 

• Source  and  object  file  editing 

• Program  checkout  and  monitor  commands 

• Resources  accounting 

3. 2. 4.4  H-6180  MULTICS 

The  MULTICS  command  language  consists  of  18  command  groups  providing 
extensive  directory  and  segment  manipulation  and  editing,  and  output  data 
formatting.  Six  of  these  command  groups  address  the  storage  system:  creating 
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and  editing  segments,  segment  manipulation,  directory  manipulation,  access 
control,  formatted  output  facilities,  and  address  space  control.  (It  should  be 
noted  that  the  virtual  memory  environment  of  the  MULTICS  system  often  tends 
to  simplify  and  reduce  the  total  job  control  language  requirements  imposed  upon 
the  user. ) In  addition  to  addressing  the  storage  system,  the  MULTICS  command 
language  also  provides  complete  and  flexible  user  control  of  program  generation, 
execution,  and  check-out;  command  entry;  resources  accounting;  communications 
with  the  system;  and  communications  between  users. 

3.2.5  FILE  MANAGEMENT  SUPPORT  SOFTWARE 

3.2.5. 1 INFQNET-1108S 

In  CSC's  Teleprocessing  System  (CSTS)  the  file  system  is  constructed  of  librar- 
ies composed  of  files.  The  system  software  resides  in  its  own  library  and  is 
of  course  protected  from  the  user.  A user  library  is  created  beginning  with  the 
creation  of  temporary  files  in  the  user  session.  At  completion  of  creation  of  the 
files,  the  files  can  (by  user  option)  be  made  permanent  and  be  assigned  to  a 
user-specified  storage  medium  (drum,  disk  packs,  or  magnetic  tape)  by  CSTS. 

If  no  storage  medium  is  specified,  CSTS  selects  the  medium.  CSTS  also  per- 
forms and  controls  all  allocation. 

In  mass  storage  allocation,  the  standard  unit  of  allocation  is  a page,  which  con- 
sists of  512  words.  CSTS  offers  two  mass  storage  allocation  techniques:  stand- 
ard and  sheaf.  The  standard  technique  uses  page  and  folio  allocation  (four  sequen- 
tial pages).  The  folio  structure  is  used  to  minimize  access  time  between 
sequential  folio  pages.  Sheaf  allocation  is  available  only  for  extremely  large 
disk  files  and  is  directly  related  to  the  physical  characteristics  of  the  storage 
device  (i.  e. , minimizing  disk  arm  positioning).  In  this  file  system,  the  user 
can  specify  his  magnetic  tape  allocations  by  command. 

All  files  created  are  addressable  by  file  identifier  and  system  and  user-generated 
file  attributes  associated  with  the  file.  Privileged  file  protection  is  provided  as 
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described  above.  Magnetic  tape  files  can  be  structured  in  standard-length 
(512  word)  physical  records  or  user -specified  nonstandard  length  records.  Unit 
record  device  handling  is  always  performed  by  CSTS  I/O  routines. 

3. 2. 5.  2 DECSYSTEM-10 

The  same  file  management  capabilities  provided  in  INFONET's  CSTS  are 
generally  provided  in  the  DECSYSTEM-10  operating  system.  Some  differences 
are: 

. • The  standard  unit  of  storage  allocation  is  a 128-word  block  or  file 

• Permanent  files  are  relocated  by  the  operating  system  to  dedicated 
user  storage  areas  (of  disk  storage) 

• Different  file  access  privileges  can  be  granted  to  multiple  (three) 
classes  of  users  of  a common  file  (described  above) 

• Additional  file  manipulation  in  the  form  of  command  program  con- 
version of  core  image  file  formats  and  DEC  tape  file  formats  is 
provided 

3. 2. 5.  3 H-6080  GCOS 

The  File  Management  Supervisor  (FMS)  provides  a common  file  system  for  all 
processing  performed  under  GCOS.  FMS  is  a hierarchical  catalog  and  file  data 
structure.  It  is  comprised  of  a System  Master  Catalog  (total  system  file  direc- 
tor) and  User  Master  Catalogs.  Below  each  User  Master  Catalog  there  can 
exist  multiple  levels  of  sub-catalogs.  This  structure  provides  a decentralized 
and  extremely  flexible  file  management  system.  Some  significant  features  of 
this  file  system  are: 

• Concurrent  updating  of  a single  data  base  can  be  made  by  many  pro- 
grams without  update  conflicts 

• Privileged  file  protection  is  provided  by  identifiers  and  attributes 

• All  mass  storage  allocation  is  controlled  by  FMS 
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• Restoration  of  files  left  incomplete  by  faulty  application  logic, 
hardware  failures,  or  system  interrupts  is  provided 

• Program  testing  can  be  performed  using  production  files  in  test 
mode 

3. 2. 5.  4 H-6180  MULTICS 

The  MULTICS  storage  system  is  a hierarchical  file  system  augmented  by  a vir- 
tual memory.  In  this  system,  all  data  and  instruction  connectivity  is  accom- 
plished by  segmentation.  All  information  in  the  system  is  organized  into  a 
hierarchical  tree  structure  composed  of  segments  connected  by  branches  and 
links.  File  management  (i.e. , the  Basic  File  System)  in  this  system  offers  the 
user  all  the  features  of  the  conventional  systems  already  discussed,  plus  the 
ability  to  make  a segment  (file)  instantaneously  shareable  by  being  directly 
addressable  in  MULTICS  programs. 

3.2.6  LCF  SOFTWARE  TOOLS  AVAILABILITY 

Some  of  the  software  tools  described  in  Volume  2 currently  are  available  in 
each  of  the  candidate  host  systems.  However,  this  is  a very  fractional  imple- 
mentation, consisting  primarily  of  the  program  development  and  integration 
tools  on  all  but  the  H-6080  GCOS  system.  A summary  of  the  current  imple- 
mentation is  shown  in  Table  3-3. 


3-17 


Table  3-3.  LCF  Software  Tools  Availability 


^'\xComputer 
LCF  ^^System 

Software  Tool^v^^ 

H-6080 

GCOS 

H-6180 

MULTICS 

INFONET- 

1108s 

DECSYSTEM-10 

Compiler  Generator 
(JOCIT) 

Yes 

No 

No 

No 

Statistics  Gatherer 
(JLMT) 

No 

No 

No 

No 

Compiler  Validation 
(JCVS) 

Yes 

Yes 

No,  but 
Impl.  Cost 
is  Negligible 

Yes 

Program  Validation 
(JAVS) 

Yes 

No 

No 

No 

Text  Editor 

Yes 

Partial 

Yes 

Yes 

Linker 

Partial 

Yes 

Yes 

Yes 

Debugging 

Partial 

Yes 

Yes 

Yes 

T ranslators 

No 

No 

Partial 

No 

3.2.7  OPERATING  ENVIRONMENT 


3.2.7. 1 Conversational  Processing 

The  first  of  three  operating  environment  requirements  for  the  LCF  host  is  con- 
versational processing.  Conversational  processing  will  be  required  to  be  per- 
formed from  the  LCF  and  users  terminals  for  the  following: 

• Local  compiler  and  program  validation  from  LCF  terminal 

• Remote  compiler  validation  from  LCF  terminal 

• Software  problem  report  and  receiver  response  from  user  terminal 

• Compiler  change  proposal  and  receiver  response  from  user  terminal 

• Remote  data  entry  of  language  statistics  from  user  terminal 

• Language  status  query  from  user  terminal 
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All  three  candidate  hosts  offer  full  interactive  processing  capabilities, 
communicating  with  both  local  and  remote  terminals. 

3. 2. 7.  2 Batch  Processing 

Batch  processing  will  be  required  to  be  performed  in  LCF  compiler  generation 
and  for  language  utilization  analysis.  Local  batch  processing  is  readily  availa- 
ble in  all  three  candidate  hosts,  while  remote  batch  processing  is  available  at 
the  expense  of  additional  software.  The  need  for  a remote  batch  capability  for 
the  LCF  can  be  eliminated  by  selection  of  a host  located  locally  to  the  LCF 
(i.e. , H-6080  and  H-6180  systems). 

3. 2. 7. 3 Timesharing 

Timesharing  is  an  LCF  host  option  in  lieu  of  a dedicated  host  computer  for  LCF 
implementation.  For  the  LCF  processing  functional  requirements  envisioned, 
implementation  of  a dedicated  computer  system  would  be  uneconomical.  This  is 
because  a currently  implemented  large-scale  timesharing  system  can  provide 
the  required  system  availability,  processing  power,  and  reliability  at  a fraction 
of  the  equipment  and  overhead  costs  of  a dedicated  system.  All  three  candidate 
hosts  offer  timesharing  capabilities  that  meet  or  exceed  this  requirement  for  the 
LCF  host. 
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3.2.8  COSTS 

3.2.8. 1 Hardware  Costs 


The  estimated  new  hardware  costs  for  implementation  of  the  H-6080  and  H-6180 
systems  as  the  LCF  host  are  shown  below. 


Unit 

Unit  Cost 

Quantity 

Total  Cost 

Teletypewriter  Terminal 

1 - GCOS 
1 - MULTICS 
1 - User 

LCF  $12, 000-$12, 400 

User  (each) 

$6, 000- $6, 200 

TIP 

$100, 000 

1 TIP  User 
Terminal 
per  User 

User  (each) 
$100,000  + Number 
of  TIP  Users 

TIP  Interface  Hardware 

$10, 000- 
$15, 000 

1 User 

User  (each) 

$10, 000-$15, 000 
provided  host  is  not 
currently  on  a TIP 

New  hardware  costs  for  implementation  of  the  INFONET-1108  or  the 
DECSYSTEM-10  systems  as  the  LCF  host  would  require  the  use  of  batch  ter- 
minals (as  described  above).  Cost  estimates  are  shown  below. 




Unit 

Unit  Cost 

Quantity 

Total  Cost 

Batch  Terminal 

$35,000- 
$40, 000 

1 - LCF  Host 

LCF  $35, 000-$40, 000 

Teletypewriter 

1 - LCF  Host 
1 - User 

LCF  $6,  000-$6, 200 
User  (each) 

$6, 000-$6, 200 

TIP 

$100, 000 

1 TIP  User 
Terminal 
per  User 

User  (each) 

$100,  000  + Number 
of  TIP  Users 

TIP  Interface  Hardware 

$10,000- 
$15, 000 

1 User 

User  (each) 

$10, 000- $15, 000 
provided  host  is  not 
currently  on  a TIP 

TIP  Batch  Interface 
Hardware 

Not 

Available 

1 - LCF 

LCF  - Not  Available 
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3.  2. 8.  2 Software  Costs 

New  software  costs  also  favor  Implementation  of  the  H-6080  and  H-6180  candidate 
host  by  a significant  margin.  This  is  because  (1)  some  of  the  software  tools  have 
been  implemented  on  the  H-6080  GCOS  system  and  (2)  the  requirement  for  the 
DECSYSTEM-10  or  INFONET  1108  remote  host  involves  local  terminal  support  and 
ARPANET  interface  modifications  costs.  The  estimated  new  software  costs  by 
system  are  given  below. 


Area  to  be  Modified 

H-6080  & H-6180 

INFONET -1108s 

DECSYSTEM-10 

Language  Specification 

50-64  mm 

50-64  mm 

50-64  mm 

JOCIT 

0 

24  mm 

24  mm 

JLMT 

28-62  mm 

28-62  mm 

28-62  mm 

JCVS 

0 

1 mm 

0 

JAVS 

0 

48-66  mm 

48-66  mm 

Host  Support  Software 

53-99  mm 

9-33  mm 

9-33  mm 

Ho  st  - AR  PA  NE  T Interface 

6-12  mm 

48-96  mm* 

48-96  mm* 

TOTALS 

137-237  mm 

208-345  mm 

207-345  mm 

* Includes  local  terminal  support  modification. 

3.3  SYSTEM  SELECTION 

3.3.1  COMPARATIVE  EVALUATION  OF  CANDIDATES 

Each  of  the  three  candidate  host  systems  was  evaluated  against  the  LCF  require- 
ments, and  in  some  instances  comparisons  of  the  three  candidate  systems  were 
performed.  However,  these  comparisons  provided  no  firm  basis  for  selection 
of  an  LCF  system  because  the  relative  importance  of  each  requirement  factor 
compared  was  not  considered.  The  purpose  of  this  section  is  to  supply  weighted 
values  to  each  of  the  requirement  factors,  and  to  provide  a side-by-side  com- 
parison of  the  candidate  systems. 
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To  compare  the  candidate  systems,  each  of  the  LCF  requirement  factors  was 
weighted  based  on  CSC's  experience  with  the  pertinent  hardware  and  software. 
Then,  by  using  the  total  set  of  weighted  LCF  requirements,  each  of  the  LCF 
candidate  systems  was  graded  on  a scale  of  100  points.  The  results  of  this 
grading,  illustrated  in  the  system  weighting  matrix  in  Table  3-4,  indicate  that 
the  H-6080/H-6180  host  candidate  is  the  logical  first  choice  with  a total  score 
of  82  points.  The  second  choice  is  the  DECSYSTEM-10  with  63  total  points. 

The  seemingly-wide  dispersion  between  the  first  and  second  choice  is  largely 
attributable  to  the  terminal  hardware  and  support  software  economy  of  using  a 
host  system  (i.e. , H-6180)  located  local  to  the  LCF,  and  to  the  software  econ- 
omy of  using  a host  system  (i.e. , H-6080)  on  which  some  of  the  LCF  software 
tools  are  already  implemented. 

3.3.2  RECOMMENDED  LCF  SYSTEM 

The  H-6080  and  H-6180  systems  offer  a number  of  significant  advantages  over 
the  other  two  candidates,  and  are  the  systems  recommended  by  CSC  for  imple- 
mentation as  the  LCF  host.  The  advantages  of  the  recommended  H-6080  and 
H-6180  systems  are: 

• Low  implementation  cost 

• Minimum  lead  time  in  procuring  new  software 

• Currently  on  ARPANET 

• Maximum  host  environment  utilization  provided 

• Maximum  data  security  provided 

Figure  3-2  shows  the  anticipated  system  interfaces  for  the  recommended  H-6080 
and  H-6180  LCF  system. 


LCF  Requirement 
Factor 


Weighting  H-6080  and 

Factor  H-6180  INFONET  DECSYSTEM-10 


New  Hardware  Costs 

12 

10 

4 

4 

New  Software  Costs 

18 

12 

7 

7 

ARPANET  Interconnection 

14 

14 

0 

14 

LCF  Software  Tools 
Implementation 

13 

8 

2 

2 

Operating  Environment 

12 

10 

8 

8 

User  Interface 

11 

8 

10 

10 

File  Management 

10 

10 

9 

9 

User  File  Protection 

10 

10 

9 

9 

TOTALS 

100 

82 

49 

63 

SECTION  4 - OPERATIONAL  PK0CEDURE_S 


4.1  GENERAL  REQUIREMENT 

The  LCF  must  be  responsive  to  the  user  while  maintaining  a standard  portable 
product.  Together  with  the  personnel  and  physical  facilities,  the  operational 
procedures  provide  the  means  to  accomplish  this  end.  This  section  outlines  the 
procedures  necessary  for  an  LCF  and  describes  the  basic  set  of  procedures. 

Once  an  implementation  is  begun  for  a specific  LCF,  these  procedures  should  be 
refined  and  expanded  to  describe  the  specific  operations  and  to  include  the  sup- 
porting software  tools.  Explicit  operating  procedures  for  the  support  staff  will 
enable  the  LCF  to  use  personnel  from  the  military  who  will  not  require  extensive 

training  or  tenure. 

4.2  OPERATING  PROCEDURES  DESCRIPTION 

The  routine  function  of  the  LCF  should  be  to  process  error  reports  and  new 
user  requirements,  deploy  current  compiler  versions,  perform  acceptance  and 
regression  testing  and  provide  compiler  software  generation  and  maintenance. 
The  procedures  required  to  perform  these  functions  are  described  in  the  follow- 
ing paragraphs. 

4.3  T.CF  TEST  SUPPORT 

Support  for  new  and  evolving  HOL  software  systems  consists  of  correcting 
errors  found  in  the  systems,  implementing  new  capabilities,  distributing 
updated  revisions  of  the  systems,  maintaining  user  documentation  and  proce- 
dures, and  providing  technical  guidance  in  the  correct  and  efficient  use  of  the 
various  features  available  in  the  systems.  To  accomplish  this  support,  rigor- 
ous methods  of  acceptance  must  be  employed.  The  recommended  detailed  pro- 
cedures for  performing  acceptance  testing  for  new  or  extensively  modified 
HOLs  are  presented  below.  Also  described  are  testing  and  acceptance  proce- 
dures for  minor  modifications  and  documentation. 
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4.3.1  ACCEPTANCE  TESTING 


The  identification  of  acceptance  criteria  is  clearly  as  important  an  activity  as 
writing  the  initial  specification.  The  two  are  intimately  related  in  that  the 
former  is  derived  exclusively  from  the  latter.  Ultimately,  the  acceptance  cri- 
teria must  be  expressed  in  the  form  of  acceptance  testing,  whose  goal  is  to  pro- 
vide a systematic  and  objective  measurement  of  the  degree  to  which  the  compiler 
has  met  the  specifications.  One  view  of  acceptance  is  that  the  compiler  is 
either  acceptable  or  not  acceptable.  However,  that  is  both  too  stringent  and 
too  idealistic.  Instead,  degrees  of  acceptability  must  be  recognized.  In 
other  words,  a compiler  may  be  usable  long  before  it  is  completely  error-free. 

The  acceptance  testing  activity  is  the  logical  culmination  of  a compiler  imple- 
mentation effort.  The  disciplined  measurement  of  performance  against  require- 
ments should  be  the  principal  governing  activity.  Acceptance  test  prepara- 
tion proceeds  with  a systematic  and  exhaustive  analysis  of  the  specifications. 

It  is  often  desirable  to  commission  a group  independent  of  the  compiler  imple- 
mentation team  to  prepare  the  acceptance  tests  for  a major  effort;  it  may  be 
accomplished  successfully  within  the  LCF  staff  or  by  an  outside  agency  under 
contract  to  the  LCF.  This  eliminates  the  tendency  to  prepare  acceptance  tests 
that  are  simply  extensions  of  the  design  or  development  tests,  and  should  aid 
in  achieving  an  objective  measurement.  Also,  where  two  different  users  are 
contributing  to  the  same  specification,  there  may  be  a conflict  of  interpretation. 
Guidelines  are  needed  for  resolving  such  conflicts.  A Configuration  Control 
Board  (CCB)  can  provide  the  vehicle  for  mediation  and  resolution. 

Whenever  the  scope  of  the  compiler  modification  is  such  that  a full  acceptance 
test  procedure  is  unwarranted  or  the  change  involves  documentation  and  not 
software  code,  a simpler  acceptance  test  procedure  should  be  used.  In  the 
case  of  documentation  changes  that  do  not  affect  software  code,  the  modified 
documentation  with  appropriately  identified  changes  is  subjected  to  review  by 


the  user  and  configuration  management  for  final  approval,  acceptance,  and 
implementation.  Minor  software  code  changes  must  undergo  an  abbreviated 
version  of  the  major  acceptance  test  procedures. 


In  the  course  of  preparing  the  guidelines  for  acceptance  criteria  specification, 
the  following  six  acceptance  test  requirements  should  be  examined: 

• Analysis  of  the  specifications 

• Preparation  of  test  plans  and  procedures 

• Test  preparation  and  validation 

• Test  materials  available  to  developers  and  testers 

• Preparation  of  test  specifications 

• Establishment  of  test  controls 

These  are  discussed  in  the  following  subsections. 

4.3.2  ANALYSIS  OF  SPECIFICATIONS 

Guidelines  should  be  used  in  the  analysis  of  the  HOL  specifications  primarily  to 
provide  meaningful  test  categories.  The  specifications  should  identify  the  per- 
formance requirements  for  the  completed  compiler  or  its  modification.  Sug- 
gested categories  include: 

• Independent  language  form  testing 

• Composite  language  form  testing 

• Diagnostic  tests 

• Accuracy  measurement 

• Capacity  measurement 

• Optimization  tests 

• Code  generation  tests 

• COMPOOL  tests 

• Tests  for  input  forms 

• Tests  to  generate  all  output  forms 

• Compilation  mode  tests 
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• Compiler  option  tests 

• Debugging  feature  tests 

• Library  tests 

4.3.3  PREPARATION  OF  TEST  PLANS  AND  PROCEDURES 

The  scope  of  the  testing  is  determined  by  the  size,  complexity,  and  criticality 
of  the  software  modification.  These  guidelines  should  be  used  to  consider  the 
following  points: 

• Identification  of  test  preparation  team 

• Identification  of  test  management  team 

• Interface  between  implementers  and  testers 

• Schedule  of  test  delivery 

• Schedule  of  required  support  software  and  hardware  deliveries 

• Other  required  resources  (e.  g. , "war  room"  space,  secretarial 
support,  technical  assistant  support,  etc.) 

• Test  case  identification 

• Test  scheduling 

• Operational  script  (test  submission,  test  verification,  result 
evaluation,  error  recording,  status  recording,  etc.) 

• Reporting  methods 

• Test  materials 

Test  plans  describe  the  tests  required  to  assure  LCF  management  and  the  cus- 
tomer that  the  compiler  project  will  perform  in  accordance  with  the  approved 
baseline  specification.  The  plans  provide  for  a sequence  of  tests  applied  from 
the  time  system  components  are  being  built  and  integrated  until  the  total  system 
is  accepted. 
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For  each  test  plan,  the  following  information  must  be  provided: 

• An  identification  of  the  individual  tests  and  their  respective 
estimated  start  and  completion  dates 

• An  identification  of  the  functions  to  be  exercised  and  checked  by 
each  test  (as  related  to  the  particular  specification  baseline) 

• The  scheduled  date  for  the  integration  of  each  function 

Scheduling  should  consider  the  interface  requirements  of  each  function  (i.  e. , data 
interfaces  through  tables  and  files  and  control  interfaces).  The  required  avail- 
ability of  some  functions  before  others  (as  specified  in  the  requirements  docu- 
ment), and  the  earliest  time  at  which  the  function  can  be  implemented  and  ready 
for  integration,  also  should  be  scheduled. 


A specification  of  testing  environment  (equipment,  operator  personnel,  hard- 
ware configuration,  special  operating  instructions)  should  be  included  in  the 
test  plan.  The  test  plan  should  identify  and  schedule  all  software  and  hardware 
required  to  support  the  test  to  compensate  for  unavailability  of  critical  functions 
or  components,  required  hardware,  supporting  software,  or  other  required  test 
resources.  The  test  plan  also  must  identify  resources  required  such  as: 

• Personnel  required  to  prepare,  execute,  and  evaluate  the  tests 

• Support  computer  programs  (i.e. , test  support  and  utility  programs 
such  as  simulation,  data  reduction,  memory  dump  programs, 
special  loaders,  and  test  input  data  generators) 

• Type  ci  aquipment  (including  the  computer)  required  during  the 
test  activity,  plus  the  required  operating  time,  duration,  and 
availability  of  each  equipment;  the  number  of  hours  required  per 
day,  week,  and  month,  plus  information  about  the  minimum  turn- 
around time  per  use  of  the  equipment 
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The  LCF  computer  operator  staff  member  should  assist  in  preparing  and 
scheduling  the  test  plan  and  should  see  that  the  tests  are  executed.  He  coordi- 
nates with  the  LCF  analysts  and  programmers  to  achieve  successful  test  results. 

4.3.4  PREPARATION  OF  TEST  SPECIFICATIONS 

The  test  specification  provides  the  basis  for  preparing,  conducting,  and  evaluat- 
ing a given  test.  It  describes  the  goals  of  the  test,  the  necessary  resources, 
the  detailed  test  procedures,  and  the  success  criteria.  A test  specification 
must  be  prepared  for  each  test  identified  in  the  Acceptance  Test  Plan.  The  test 
specification  should  be  reviewed  and  approved  in  accordance  with  additional 
guidelines  to  be  established. 

In  developing  the  test  specification  guidelines,  the  following  points  must  be 
addressed: 


• Test  objectives  - The  purpose  of  the  test,  including  the  functions  or 
specifications  that  the  test  intends  to  prove 

• Test  prerequisites  - A specification  of  tests  that  must  be 
completed  and  equipment  that  must  be  available  before  this 
test  can  be  run 

• Input  values  - The  precise  input  values  to  be  used  or  the  method 
to  be  used  in  generating  the  inputs 

• Initialization  values  - Static  values  for  data  items  that  are  not 
part  of  the  dynamic  test  input 

• Output  values  - The  expected  output  values  that  are  considered  to 
be  indicative  of  a successful  test;  in  cases  where  a given  range 
or  frequency  is  to  be  considered  for  success,  the  information 
should  be  identified 
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• Range  of  parameters  - The  upper  and  lower  limits  of  numerical 
values;  appropriate  symbology  for  nonnumeric  data 

• Analysis  techniques  - Procedures  to  be  followed  in  determining 
if  outputs  are  acceptable 

4.3.5  TEST  PREPARATION  AND  VALIDATION 

To  eliminate  unnecessary  duplication  of  effort,  the  guidelines  should  aid  in 
identifying  existing  sets  of  known  tests  for  particular  languages,  e.  g. , the 
JCVS  series  for  J-3  and  J73/I  JOVIAL.  Testing  extra-language  features 
invariably  requires  the  preparation  of  additional  tests.  Guidelines  for  test 
preparation  must  cover  such  subjects  as  coding  standards,  use  of  COMPOOLs 
for  standard  data  descriptions  and  target  parameterization,  schedules,  criteria 
for  independence  of  subtests  (i.e. , are  the  results  of  one  test  required  for  a 
subsequent  test?),  method  of  result  display  (monitoring,  stylized  success  or 
failure  announcements,  postmortem  dumps,  etc.). 

The  problem  of  validation  is  not  an  easy  one.  For  standard  tests,  such  as  the 
JCVS  series,  the  tests  will  have  been  validated  through  previous  exercise.  For 
modifications  to  existing  HOLs,  existing  tests  may  suffice  or  may  need  to  be 
modified.  Where  new  tests  are  developed,  the  only  hope  of  validation  lies  in 
the  availability  of  an  existing  version  of  a compiler  for  the  same  language.  The 
tests  then  may  be  partly  exercised  and  debugged  using  that  compiler. 

Where  there  is  no  compiler  available  except  the  one  under  development,  the 
guidelines  may  suggest  use  of  prerelease  versions  of  the  compiler  at  least  for 
syntax  checking,  if  not  for  result  verification.  In  this  last  case,  the  acceptance 
test  period  must  combine  compiler  measurement  with  test  case  checkout.  The 
guidelines  should  discuss  how  this  condition  may  dictate  the  division  of  the 
acceptance  period  into  two  phases;  the  first  to  be  dedicated  to  test  case  checkout 
with  attention  to  fast,  somewhat  informal  compiler  error  reporting  and  cor- 
rection; the  second  to  be  dedicated  to  the  formal  acceptance  measurement  of  the 
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compiler.  In  addition,  the  relevance  of  formal  validation  committees  to  this 
problem  will  be  examined,  and  the  results  will  be  included  in  the  LCF 
newsletter. 

4.3.6  ESTABLISHMENT  OF  TEST  CONTROLS 

Test  control  is  embodied  in  a set  of  procedures  for  use  during  the  acceptance 

test  phases  of  the  project  such  that  the  test  activity  can  be  performed  in  a sys- 

\ 

tematic  and  economic  manner. 

The  basic  activities  to  be  controlled  during  the  testing  phase  are: 

• Application  of  tests  to  a given  system  or  program 

• Communication  of  information  pertaining  to  discrepancies 

• Analysis  of  discrepancies  to  determine  the  cause  and  solution 

• Implementation  and  testing  of  the  solution 

• Reissuance  of  the  system  or  program  for  further  testing;  providing 
the  necessary  documentation  of  its  differences  from  the  previous 
version  of  the  system 

4.4  MONITORING  HOL  SOFTWARE  SUPPORT 

The  three  principal  control  elements  required  to  be  monitored  for  compiler 
analysis,  production,  modification,  and  acceptance  testing  activities  are: 

• Software  error  processing 

• Software  change  control  procedures 

• System  release  procedures 

To  allow  the  LCF  to  give  efficient  and  timely  service,  a file  must  be  maintained 
for  each  user.  Each  prospective  user  must  provide  the  following  information: 

• Identification  of  the  project(s)  that  the  HOL  compiler  will  support 

• Hardware  configuration 

• Specific  user  contact  for  technical  interface 


A 


4-8 


• Type  and  criticality  of  application 

• Availability  and  source  of  funding 

Whenever  any  changes  occur  in  any  of  the  above,  the  user  must  notify  the  LCF. 
Periodically,  the  LCF  should  supply  questionnaires  to  reaffirm  or  update  this 
information. 

Established  control  methods  and  procedures  are  summarized  in  the  following 
paragraphs.  Guidelines  for  controls  should  be  derived  and  expanded  from  these 
summaries. 

4.4.1  SOFTWARE  ERROR  PROCESSING 

The  Software  Problem  Report  (SPR)  is  used  to  document  and  communicate  to  the 
appropriate  analysts  the  information  pertaining  to  discrepancies  in  the  execution 
of  a given  test.  The  SPR  (see  Figure  4-1)  or  its  equivalent  should  be  used  to 
report  discrepancies  discovered  during  the  acceptance  testing  activity.  The 
SPR  should  be  reviewed  by  the  responsible  test  management  team  to  verify  that 
the  discrepancy  is  valid  and  that  the  necessary  information  was  provided.  The 
SPR  then  should  be  forwarded  to  the  LCF  manager  or  his  delegate  for  resolution. 
The  basic  elements  of  the  SPR  must  provide: 

• Description  of  the  discrepancy  to  the  analyst  such  that  he  can 
determine  variations  between  expected  and  actual  output  of  the 
test  rim;  differences  from  previous  runs  of  the  same  test; 
suspected  problem  areas ; and  specific  data  causing  the  problem 

• Specification  of  the  run  termination  status 

• Indication  of  the  severity  of  the  discrepancy 

• Provision  for  a reference  to  the  proper  supporting  material 

• Allowance  for  a preliminary  response  to  the  discrepancy  before 
its  correction 
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SOFTWARE  PROBLEM  REPORT 


SPR  No. 


PROBLEM  (Prepared  By  User) 
Or.g.nafor 

(N.ime) 

System.  Processor,  or 
Component  Fa*  *ng  _ _ 

Of  Project  Involved 


(Organization) 


System 
. Version  10  < 


Classification  Description  of  Problem  (Attach  additional  pages  if  necessary-include 

D Minor  or  Not  to  Specs  l,ne  number*  of  other  identification  of  offended  statements  or  data) 

□ Major  or  Missing 

□ Information 

□ Revision  Request 

D Software  Addition 

Correction  Required  By 

Date 

Authorizing  SiQnature  Date  _ _ 

(Name)  (Organization) 


ANALYSIS:  (Prepared  by  organization  responsible  for  software) 


Test  Case  or 

— Program  ID  ' ■’ 

Enclosures 

O Pfogram  Listings 
O Run  Deck 
D Run  Instructions 
D Storage  Map  Listings 
Q Data  Listings 
D Online  Output 


Received  Date  , Time  — 

□ Software  in  Error  Explanation:  - 

Q Restriction  Required  - 

I""!  Circumvention  Required  - 

p]  Software  Not  in  Error 

Explain  and  Return  to  Originator 

r-t  Insufficient  Information  for 

•""*  Analysis.  See  Explanation  

P"l  Error  Previously  Reported  - 

LJ  On  SPR  No. 


LCF  Charge  Number:  . 


Analysis  Time  Expended: 
Man  Hours  _________ 

Computer  Hours  

Computer  

Estimated  Cost  of  Solution: 

Man  Hours  

Computer  Hours  . 

Planned 

Correction  Date 


D Others,  Explain  Correction  Date 

H Not  Approved  Q Approved  for  Correction  or  Change 

Signature  . Date  _ Time 

(Name)  (Organization) 


CORRECTION:  (Brief  description  of  work  performed,  including  test  cases  used  to  confirm  correction) 

Solution  Modules  Changed^ 


Work  Performed  by  (Signature)- 


Correction  Time  Expended: 
Man  Hours  - 
Computer  Hours 
Submitted  to 
Time  — 


CONFIRMATION  (Co.rfct.on  Verifwd  by:  LCF  MANAGER 

Dim 

, Time  . 

(Signature) 

Available  »n  (Version  101 

Date  Returned  to  Originator 

Time 

i 

Figure  4-1.  Sample  Software  Problem  Report  (SPR)  Form 
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Since  users  will  be  reporting  all  problems  electronically  over  a semi-automated 
teleprocessing  network,  the  hardcopy  printouts  received  at  the  LCF  must  be 
analyzed  to  determine  if  the  reported  problem  is  due  to  software  error,  or  if  it 
requires  a specification  change  to  accomplish.  If  the  problem  is  deemed  to  be 
a software  error,  the  hardcopy  printout  is  stapled  to  an  SPR  form  and  processed 
the  same  as  the  development  SPRs.  If  the  problem  is  deemed  to  require  a 
specification  change,  the  LCF  analyst  must  complete  and  submit  a Language/ 
Compiler  Change  Proposal  (L/CCP).  The  L/CCP  is  then  submitted  to  the  Con- 
figuration Control  Board  (CCB)  for  processing  as  a change  request.  In  report- 
ing problems,  the  user  must  submit  the  following  information: 

• Originator  - Last  name,  initial,  department,  and  telephone 
number  of  the  person  reporting  the  problem 

• Activity  - The  site  where  the  problem  was  observed 

• Location  - The  reporting  activity's  address 

• Date  error  found  - The  actual  date  of  the  discovery  (not  necessarily 
the  date  the  HOLTR  was  completed) 

• Problem  description  - A summary  of  the  problem  which  can  be 
used  to  enable  the  duplication  of  the  problem 

• Supporting  data  - The  events  and  actual  system  responses  which 
led  to  the  discovery  of  the  problem;  specific  related  data  such  as 
listings,  memory  map,  memory  dump,  etc. , which  will  enable  a 
programmer  to  recreate  the  problem 

• Project  - The  project  which  was  using  the  system  for  software 
development 

• Project  HOLTR  number  - For  local  project  use,  if  desired 

• System  and  version  - The  support  system  against  which  the 
problem  is  being  reported  (include  a specific  version  identification 
and  the  revision  number) 
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Modification/patches  - All  patch  modifications  made  to  the  system 
tape  revision 


r 


• Impact  - The  effect  the  problem  has  on  project  software  development: 

1.  A fatal  error;  the  system  is  inoperable 

2.  A serious  error  - 

a.  Error  recovery  is  possible  but  difficult 

b.  A moderately  serious  problem;  the  system  is  operable, 
but  it  is  difficult  to  recover  from  errors 

3.  A routine  error;  error  recovery  is  simple 

4.  A minor  error  or  annoyance 

5.  An  insignificant  error  or  no  error  at  all 

• Host  machine  - The  machine  on  which  the  compiler  was  running 

• Target  machine  - The  target  machine  for  which  object  code  was 
being  generated 

• How  found  - The  means  used  to  discover  the  problem,  such  as 
listing  check,  document  review,  or  compiler  operation 

• References  - When  reporting  problems  relating  to  conflicts  between 
system  performance  and  documentation,  identify  the  specific 
referenced  document  by  number,  page  and  paragraph 

The  LCF  assigns  a control  number  to  each  SPR  to  help  to  monitor  the  flow  of 
SPRs  through  a cycle  of  analysis,  correction,  and  system  update. 

Within  the  LCF  there  should  be  a quality  assurance  (QA)  group  activity,  which 
creates  tests  to  reproduce  errors  reported  on  SPRs.  These  tests  become  a 
part  of  a basic  QA  program  for  the  certification  of  all  future  compiler  releases. 

Technical  LCF  staff  members  screen  SPRs  to  determine  if  the  problems  can 
be  reproduced  from  the  information  provided  by  the  user.  The  user-assigned 
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priority  number  also  is  reviewed  to  ensure  it  has  been  assigned  properly. 
Priorities  are  as  follows: 


• Priority  1 - A fatal  error;  the  system  is  inoperable 

. 

• Priority  2 - A serious  error;  one  which  makes  error  recovery 
difficult  but  not  impossible;  the  system  is  operable,  but  it  is 
difficult  to  recover  from  errors 

• Priority  3 - A routine  error;  error  recovery  is  simple 

• Priority  4 - A minor  error  or  annoyance 

• Priority  5 - An  insignificant  error  or  not  a reproducible  error 

During  the  initial  analysis  of  an  SPR,  if  the  LCF  development  staff  believes 
a user-assigned  priority  should  be  changed,  the  staff  should  contact  the  user 
by  telephone  for  concurrence  on  the  change.  The  staff  should  not  make  arbi- 
trary unilateral  changes  to  an  SPR  priority. 

4.4. 1.1  Error  Analysis 

In  addition  to  problem  reporting,  the  SPR  is  used  for: 

• The  analysis  of  the  problem  resulting  in  one  of  the  following 
conditions,  with  the  appropriate  explanation  of  the  conclusion: 

The  software  component  was  in  error 

- The  software  was  not  in  error;  the  test  was  in  error,  or 
the  supporting  software  or  hardware  failed  or  the  specifica- 
tions were  in  error;  the  SPR  was  a comment  or 
r ecommendation 

- There  is  not  enough  information  available  for  proper  analysis; 
in  this  case,  proper  instructions  must  be  given  to  the  originator 
of  the  SPR  such  that  the  required  information  can  be  obtained; 
the  analyst  may  be  required  to  work  with  the  originator 

The  error  was  a duplicate  of  a previously  reported  error 
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The  changes  required  to  the  documentation,  including  document 


errors 

• The  manpower  and  computer  time  expended  on  the  analysis 

• An  estimated  cost  of  solution 

• The  resolution  of  the  problem  including  a description  of  work 
performed,  the  testing  performed,  and  a plan  for  the  reintegration 
and  system  testing  of  the  failing  components 

4. 4. 1.2  Error  Status  Report 

A status  report  is  prepared  in  accordance  with  Figure  4-2.  Current  and 
cumulative  statistics  on  SPRs  received,  analyzed,  and  corrected  are  recorded 
on  the  first  half  of  this  report.  The  statistics  should  be  derived  from  a review 
of  each  outstanding  SPR  by  the  appropriate  language  specialist. 

The  second  half  of  the  status  report  records  current  and  cumulative  statistics 
on  SPRs  reported  against  components  in  error.  These  statistics  should  give 
LCF  management  visibility  of  software  problems  and  correction  activity,  as 
well  as  information  pertaining  to  component  reliability. 

This  report  should  be  communicated  to  all  users. 

4.4.2  SOFTWARE  CHANGE  PROCESSING 
4. 4. 2.1  Change  Requests 

Requests  for  changes  should  be  communicated  on  standard  change  proposal 
forms  (Figure  4-3).  The  same  form  is  used  to  convey  two  kinds  of  requests, 
language  changes  and  compiler  changes. 

Change  proposals  are  completed  and  submitted  by  LCF  staff  members,  either 
as  an  original  change,  or  in  response  to  a user  problem.  Users  may  submit 
change  proposals  directly,  where  it  is  obvious  that  a problem  requires  a 
specification  change.  The  originator  completes  the  front  portion  of  the  form 
The  reverse  side  is  reserved  for  use  by  the  LCF  development  staff.  Supporting 
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LANGUAGE/COMPILER  CHANGE  PROPOSAL 


Site  Name  and  Address 


Project  Name 


Name  of  Originator 


Autovon/Phone 


Specify  the  Language/Compiler 


The  proposed  change  is 

— Critical.  (A  major  factor  in  the  success  and  timely  completion  of  the  project/ 

Important  (Would  greatly  assist  the  project  and  provide  greater  system  flexibi'ity,  but  is  not  critical) 

, . Routine  ( Nice  to  Have  ") 


Describe  the  proposed  change  (Attach  extra  sheets  if  necessary) 


Justify  the  proposed  change  (Include  reasons  for  placing  it  in  the  Critical  or  Important  categories) 


• *•  v*l<x  I V<jn«itir9 


Date 


*ui  • • H.impl.  I unguaKt'/ Compiler  Change  Proposal  Form  (1  of  2) 


Date 

Received 


THIS  SIDE  FOR  LCF  USE  ONLY 


Internal 

C/LCP  Meeting 

Assigned  to: 

C/LCP  No. 

Date 

/ / 

/ / 


Appraisal  and  recommended  solution  or  reason  for  disapproval: 


Circle  Assignment  Priority: 
Urgent  Routine 


Host  System: 


Target  System: 


Action  taken: 


Site  sensitive:  If  yes,  circle: 


Special  implementation 
■ for  C/LCP  originator 


Originator 

only 


Hardware 

dependent 


Appro>«d  for  next 
major  revision 


Disapproved 


Approximate  target  Authorizing  signature 
implementation  date: 


/ / 


/ / 


Figure  4-3.  Sample  Language/Compiler  Change  Proposal  Form  (2  of  2) 
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documentation  describing  the  requested  change  should  be  included  with  an 
L/CCP.  The  LCF  librarian  assigns  an  internal  control  number  to  each  L/CCP 
to  aid  in  monitoring  its  progress  through  the  review,  design,  test,  implementa- 
tion, and  release  cycles. 

4. 4. 2. 2 Change  Control 

Change  control  is  the  most  visible  aspect  of  configuration  management,  since 
the  people  in  this  activity  evaluate  and  approve  or  disapprove  change  requests, 
as  well  as  requests  for  deviation  or  waiver  of  technical  requirements.  The 
purpose  of  change  control  is  to  prevent  unnecessary  or  marginal  changes  while 
expediting  the  approval  and  implementation  of  the  worthwhile  ones,  i.e. , those 
that  are  necessary  or  promise  significant  benefit  to  the  customer.  Such  changes 
are  those  that  will: 

• Correct  deficiencies 

• Significantly  improve  operational  effectiveness  or  reduce  logistic 
support  requirements 

• Result  in  substantial  life-cycle  cost  saving 

• Prevent  slippage  in  an  approved  production  schedule 

In  addition  to  change  decision-making,  change  control  includes  the  equally 
important  functions  of  setting  change  priorities  (i.  e. , emergency,  urgent,  or 
routine)  and  of  ensuring  that  necessary  instructions  and  funding  authorizations 
are  issued  promptly  for  approved  changes.  These  responsibilities  are  the 
domain  of  a Configuration  Control  Board  (CCB). 

A CCB  should  be  established  early  in  the  development  phase  of  an  HOL  project. 
During  this  phase  it  should  consist  of  the  LCF  manager,  his  Air  Force  monitor, 
and  selected  LCF  software  analysts.  After  release  of  an  HOL  and  related 
compilers  to  the  users,  each  HOL  user  agency  should  have  a member  on  the 
board. 
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The  board  is  responsible  for  all  decisions  and  actions  pertaining  to: 


• Establishing  the  classification,  type,  and  priority  for  each 
proposed  change 

• Determining  the  impact  of  each  proposed  change  on  all  elements 
of  the  LCF 

• Authorizing  change  implementation 

• Review  of  all  baseline  document  (specification)  changes 

• Scheduling  the  change 

• Maintaining  the  status  of  changes  and  ensuring  follow-up  on 

the  schedule 

The  LCF  manager  is  the  chairman  of  the  board.  After  thorough  analysis  and 
discussion  of  the  proposed  change  action,  the  chairman  shall  make  the  binding 
decision.  The  overall  processing  of  a change  proposal  is  shown  in  Figure  4-4. 

4.4.3  SYSTEM  RELEASE  PROCEDURES 

Newly  developed  or  changed  HOL  software  and  documentation  must  be  released 
in  a controlled  manner.  If  different  versions  of  a language  or  its  compilers  are 
released  to  different  users,  a means  of  identifying  and  tracking  the  contents  of 
the  software  must  be  provided.  Similarly,  the  related  documentation  (if  different) 
must  contain  identifying  information  for  each  user.  Since  maintaining  different 
software  packages  can  be  very  expensive  (and  easy  to  confuse),  it  is  highly 
recommended  that  only  one  standard  software  package  be  released  at  any  one 
time  for  an  HOL.  Should  users  find  it  necessary  to  make  modifications  for  their 
own  facility,  they  do  so  at  the  risk  of  not  being  able  to  ask  for  LCF  assistance 
if  problems  arise. 

4.5  PROCEDURES  SUMMARY 


To  concurrently  develop,  operate,  and  modify  HOLs,  it  is  important  that 
changes  be  made  to  the  language  in  a controlled,  systematic  manner  and  that 


HOLD  in  abeyance 
FOR  FUTURE 
IMPLEMENTATION 


DISAPPROVE 


RETURN  TO 
REQUESTOR  WITH 
EXPLANATION 


Figure  4-4.  Functional  Flow  of  Change  Proposal  Requests 


information  be  collected  to  correct  language  deficiencies,  improve  language 
capabilities,  and  monitor  relationships  with  various  users. 

All  LCF  development  projects  should  have  detailed  change  control  procedures 
documented,  reviewed,  and  approved  by  line  management  early  in  the  develop- 
ment phase. 

4. 5. 1 CHANGE  CONTROL 

Changes  are  usually  initiated  for  one  of  the  following  reasons: 

• The  user's  needs  may  change  or  become  better  known  to  him, 
and  thus  new  requirements  must  be  added  or  capabilities  must 
be  modified  or  deleted 


• Use  of  an  HOL  is  expanded  and  the  requirements  of  the  new  users 
must  be  considered 


' 


• Documentation  may  be  unclear  or  incorrect  and  thus  must  be 
modified 

• An  HOL  implementation  may  not  perform  according  to  specifica- 
tions, or  the  design  may  not  meet  the  requirements 

• During  modification  or  development,  the  due  date  may  be  changed 

An  LCF  control  function  should  be  established  for  change  activity,  and  should 
be  staffed  by  the  librarian,  who  reports  directly  to  the  LCF  manager.  The 
librarian  should  have  full  responsibility  to  log,  monitor,  follow-up,  and  control 
all  change  requests  and  problem  reports  concerning  HOLs,  whether  they  con- 
cern compilers,  hardware,  communications , operating  system  software,  appli- 
cations software,  operating  procedures,  or  any  other  portion  of  the  development 
activity.  To  discharge  this  responsibility,  the  formal  procedures  outlined 
must  be  established  for  collecting  and  processing  problem  reports  and  change 
requests. 


1 
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4.5.2  COMMUNICATIONS 


Through  established  procedures,  the  necessary  information  can  be  collected 
and  handled  promptly,  providing  feedback  to  originators  as  well  as  other  user 
groups.  The  flow  of  information  has  been  planned  to  enhance  the  communication 
of  fundamental  facts  from  and  to  the  user.  Section  2 has  described  this  informa- 
tion flow,  and  it  is  summarized  in  Table  A-9  in  Appendix  A. 

Problem  reports  and  change  proposals  may  be  originated  by  anyone  associated 
with  the  system,  hi  order  to  conserve  analysis  resources,  management 
approval  should  be  required  for  all  requests.  As  each  communication  or  request 
is  received  by  the  control  point,  it  should  be  logged  and  assigned  for  action. 

The  log  should  be  monitored  by  the  LCF  manager  to  assure  that  timely 
responses  to  problems  and  requests  are  made. 

4.5.3  ST  ATUS  RE  PORTS 

Formal  HOL  status  reports  will  be  published  in  the  LCF  quarterly  newsletter. 
This  newsletter  will  provide  users  with  information  on  the  current  status  and 
future  development  of  the  higher  order  languages.  It  will  also  include  news 
about  recent  HOL  development  acceptances,  planned  HOL  development,  changes 
made  on  scheduled  revisions,  and  a summary  status  of  active  language  change 
proposals.  In  addition,  monthly  status  reports  of  SPRs  and  L/CCPs  should  be 
sent  to  all  users,  and  any  change  that  greatly  impacts  the  user  will  be  com- 
municated by  the  most  expeditious  means  available. 

4.5.4  ANNUAL  USER  GROUP  MEETING 

An  annual  user  group  meeting  should  be  conducted  at  the  LCF.  Among  other 

things,  this  meeting  should  include  formal  announcements  of  training  classes, 

new  materials  to  be  offered,  and  requests  for  future  agenda  items.  Another 

purpose  of  the  user  group  meeting  should  be  to  inform  users  of  the  current 

v 

status  of  the  higher  order  languages  and  to  permit  an  exchange  of  information 
between  the  LCF  and  the  user  community. 


4-22 


1 


The  topics  of  facility  staffing,  design,  and  costs  that  are  presented  in  this  section 
apply  to  controlling  a single  HOL  from  a single  LCF.  First,  the  personnel 
staffing  needs  for  the  LCF  are  described  in  detail.  This  description  includes 
the  definition  of  the  personnel  organization  structure , the  personnel  qualifica- 
tion requirements  for  each  proposed  staff  member,  and  the  manpower  resources 
of  Air  Force,  civil  service,  and  Government  contractors  from  which  the  per- 
sonnel staff  can  be  formed.  Next,  the  facility  design  is  addressed.  This  includes 
definition  of  the  computer  terminal  equipment  and  office  equipment  required  for 
the  facility.  Also  included  is  a typical  floor  plan  and  the  estimated  air  con- 
ditioning, electrical  power,  maintenance,  and  consumable  item  requirements 
for  implementation  of  the  facility.  Then,  cost  estimates  for  the  facility  are 
developed.  The  method  by  which  the  cost  estimating  is  performed  differentiates 
between  the  costs  of  initial  setup,  ongoing  operation,  and  continuing  maintenance. 
The  cost  estimates  developed  consist  of  independent  cost  parameters  that  reflect 
all  costs  associated  with  facility  hardware,  software,  communications,  and 
manpower. 

5.  1 STAFFING  AND  MANAGEMENT  NEEDS 
5.  1.  1 LCF  ORGANIZATION 

The  LCF  must  be  staffed  and  managed  in  a manner  that  both  supports  the  stand- 
ardization of  HOLs  and  recognizes  the  requirements  of  the  user.  The  organiza- 
tion must  be  consistent  with  the  procedures  described  in  Section  4 and  the 
present  RADC  organizational  structure.  Such  an  organizational  structure  for  a 
single  LCF  is  shown  in  Figure  5-1.  Organizational  and  staffing  considerations 
for  multiple  HOLs  are  included  in  Section  6. 
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Figure  5-1.  Proposed  LCF  Organizational  Structure 
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The  LCF  organization  must  exist  independently  from  the  HOL  users  but  respon- 
sible to  the  same  higher  authority.  This  ensures  that  neither  group  can  enforce 
unacceptable  requirements  upon  the  other  but  that  a common  higher  authority 
can  mediate  disputes.  The  recommended  management  techniques  and  organiza- 
tional structure  are  such  that  these  differences  can  seldom  (and  possibly  never) 
occur. 

5.  1.  1.  1 LCF  Manager 

The  LCF  manager  must  be  experienced  in  directing  and  monitoring  computer 
system  programs  and  activities  involving  one  or  more  HOLs  and  preferably 
should  have  experience  in  language  development.  This  position  requires  a 
bachelor's  degree  in  computer  science,  mathematics,  or  a related  science,  or 
business  administration  with  a strong  mathematics  or  data  processing  emphasis. 
The  manager  will  supervise  two  groups  of  personnel  and  preside  over  the  Change 
Control  Board.  The  groups  are  (1)  Analysis  and  Programming  and  (2)  LCF 
Operations.  This  position  is  the  equivalent  to  Computer  Systems  Staff  Officer, 
Air  Force  Specialty  Code  (AFSC)  5116;  Computer  Specialist,  Civil  Service 
GS-13;  or  Manager  of  Systems  Programming  in  private  industry  as  described 
in  the  A.  S.  Hansen,  Inc.  , survey  as  reported  in  the  January,  1976  issue  of 
Datamation,  Volume  22,  Number  1,  pp.  73-87.  A specific  job  description  for 
the  LCF  Manager's  position  is  presented  later  in  this  section. 

5.  1. 1.  2 LCF  Operations 

The  LCF  Operations  group  is  responsible  for  operating  the  hardware  and 
communications  system  and  for  receiving,  logging,  and  sending  communica- 
tions. The  operations  functions  must  be  standardized,  and  a complete  set  of 
operating  procedures  must  be  prepared  as  discussed  in  Section  4.  The  per- 
sonnel required  to  staff  this  group  includes  a lead  operator,  supported  by  an 
additional  operator  and  managed  by  an  operations  manager  where  the  size, 


complexity,  and  multiplicity  of  HOLs  require  additional  personnel.  A librarian 
also  must  be  included  to  record  all  incoming  LCPs,  CCPs,  status  inquiries, 
and  user  communications;  to  maintain  status  of  all  active  and  closed  tasks;  to 
support  communications  from  the  LCF  to  the  user;  to  maintain  current  configura- 
tion status  information;  and  to  coordinate  configuration  changes  transmitted  to 
the  user. 

5.  1. 1.  3 Analysis  and  Programming 

The  Analysis  and  Programming  group  is  responsible  for  evaluating  problems  and 
requests  for  changes;  answering  user  questions;  performing  and  testing  approved 
compiler  changes;  maintaining  complete,  current,  and  consistent  documentation; 
and  recommending  compiler  improvements.  The  personnel  in  this  group  must 
be  language  analysts,  programmers,  and  documentation  specialists  familiar  with 
HOLs,  compiler  construction,  and  the  specific  language  or  languages  to  be  sup- 
ported and  controlled  by  the  LCF.  The  number  of  each  job  classification  depends 
upon  the  particular  HOL  or  HOLs  involved,  and  a separate  manager  may  be 
necessary,  depending  on  the  size  of  the  group. 

5.  1.  2 MANPOWER  RESOURCES 

The  recommended  staffing  of  the  LCF  is  predicated  upon  the  availability  of 
appropriately  skilled  personnel  and  well-defined  job  responsibilities  and  operat- 
ing procedures.  Knowledge  and  experience  is  especially  critical  in  the  language 
analysis  and  programming  functions.  A successful  management  background  and 
an  understanding  of  HOL  concepts  is  necessary  for  the  LCF  manager. 

The  remaining  positions  can  be  defined  better  as  to  specific  job  requirements 
and  supported  by  detailed  procedures  so  that  greater  staffing  flexibility  is 
possible.  If  multiple  HOLs  are  to  be  considered,  the  selection  of  the  manager 
becomes  the  most  critical  consideration.  The  job  description  for  each  position 
is  described  below. 
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5.  1.  2.  1 Language  Control  Facility  Manager 


5.  1.  2. 1.  1 Job  Summary 

The  Language  Control  Facility  manager  administers  and  monitors  HOL  programs, 
including  policy  planning,  program  formulation,  funding  and  direction  of  activities 
concerned  with  HOL  analysis  and  control;  software  design,  development,  testing, 
maintenance,  and  documentation;  and  operation  of  computer  facilities. 

5.  1.  2.  1.  2 Duties  and  Responsibilities 

The  Language  Control  Facility  manager  performs  duties  and  assumes  responsi- 
bilities as  follows: 

• Formulates  HOL  standards  and  policies  - Formulates  and  administers 
policies,  concepts,  and  procedures  to  ensure  effective  and  efficient 
use  of  HOLs  and  computer  systems;  keeps  abreast  of  and  adheres 

to  current  Air  Force  and  DOD  standards  and  regulations;  evaluates 
technical  problems  and  economic  factors  related  to  language  research, 
various  HOL  adaptations,  and  computer  systems  applications;  recom- 
mends changes  to  HOLs  or  HOL  applications  in  response  to  user 
requirements,  economic  factors,  and  technological  development; 
and  establishes  HOL  objectives  consistent  with  AF  computer  system 
objectives. 

• Coordinates  computer  systems  activities  - Advises  commander  and 
staff  on  advanced  concepts  involving  HOLs;  develops  and  provides 
operating  budget  information;  provides  independent  appraisals  of 
HOLs  and  HOL  applications;  assists  in  the  isolation  of  factual 
information;  and  recommends  appropriate  courses  of  action. 

Assures  that  proposed  concepts  fulfill  user  requirements  and  are 
technically  feasible;  provides  cost  estimates;  assists  in  determining 
feasible  development  and  implementation  schedules.  Schedules 
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and  conducts  configuration  control  meetings  to  review  pending 
requirements,  current  status,  and  completed  tasks  for  the  Language 
Control  Facility.  Represents  the  commander  in  computer  systems 
matters  and  maintains  liaison  with  subordinate  and  higher  head- 
quarters. Maintains  appropriate  liaison  with  electronic  data  process- 
ing equipment  manufacturers  to  obtain  latest  information  regarding 
technological  developments  in  equipment  and  techniques.  Monitors 
the  performance  of  contractual  provisions  concerning  leased  or  pur- 
chased automatic  data  processing  equipment. 

• Monitors  and  directs  computer  systems  activities  - Provides  direction 
and  monitors  progress  of  HOL  control  functions  such  as  language 
analysis  design,  modification,  documentation,  development,  testing, 
and  application;  manages  language  analysts  and  programmers  and 
operation  of  the  LCF  computer  processing  and  communications 
facilities;  establishes  programs  and  recommends  procedures  to 
ensure  adherence  to  policy  guidance  and  standards  and  to  interpret 
and  apply  these  for  HOL  user  applications;  establishes  and  monitors 
training  programs  for  the  LCF  staff  and  users;  evaluates  HOL 
requirements  to  support  proposed  computer  systems,  performs 
technical  audits  of  existing  computer  installations  to  assure  standardi- 
zation and  to  monitor  HOL/compiler  configurations,  and  recommends 
improvements  based  on  observations. 

• Chairs  the  Configuration  Control  Board 
5. 1.  2.  1.  3 Qualifications 

A bachelor's  degree  in  a scientific  or  administrative  discipline,  preferably  com- 
puter science,  mathematics,  business  administration,  or  engineering;  a 
master's  degree  is  desirable  but  not  mandatory;  the  manager  must  have  knowledge 
of  capabilities,  limitations,  costs,  performance,  and  applications  of  HOLs 


and  compilers  used  in  support  of  Air  Force  projects.  The  total  educational 
and  experience  background  must  clearly  demonstrate  the  ability  to  perform 
administrative,  supervisory,  managerial,  and  professional  work  of  a high  level 
of  complexity  in  the  field  of  computer  science,  with  at  least  one  year  of  experience 
at  the  equivalent  of  the  next  lower-level  grade  of  data  processing  management. 

5.  1.  2.  2 Programming  Language  Analyst 

5.  1.  2.  2.  1 Job  Summary 

The  Programming  Language  Analyst  provides  HOL  and  compiler  software  expert- 
ise; analyzes,  plans,  and  manages  the  development,  maintenance  and  documenta- 
tion of  compilers,  assemblers,  executive  and  control  programs,  and  supporting 
utility  programs;  plans  and  supervises  programming,  validation,  and  verifica- 
tion of  HOL  compilers. 

5.  1.  2.  2.  2 Duties  and  Responsibilities 

The  Programming  Language  Analyst  must  perform  the  duties  and  assume  the 
responsibilities  outlined  below: 

• Formulates  computer  systems  plans  and  designs  - Develops  plans  and 
procedures  for  computer  systems  HOL  design,  development,  test 
and  evaluation,  and  program  integration;  determines  performance 
specifications  for  HOL  and  relates  system  specifications  to  equip- 
ment and  software  characteristics;  specifies  and  designs  HOLs, 
defines  equipment  configuration,  software  requirements,  communica- 
tions interface,  data  requirements;  data  storage,  retrieval,  and 
maintenance  methodology;  data  control  techniques  and  documentation 
plan. 
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• Develops  HOL  design  specifications  - Plans  for,  modifies,  and 
maintains  executive  and  control  routines,  assemblers,  compilers, 
and  utility  programs.  Divides  program  requirements  into  logical 
parts  and  determines  how  these  parts  will  interact  in  terms  of 
sequencing,  timing,  and  storage  requirements.  Defines  and  works 
within  known  constraints,  such  as  limited  storage  space,  time,  or 
input/output  speeds.  Develops  and  specifies  tests  to  measure  com- 
piler performance  . Produces  program  design  specifications,  flow- 
charts, and  test  procedures  for  documentation. 

• Plans  and  designs  HOL  compilers  and  modifications  - Confers  with 
functional  agencies  requiring  HOL  support.  Analyzes  functional 
requirements  and  translates  these  into  computer  program  specifica- 
tions; designs  and  prepares  program  logic,  symbolic  formulation, 
block  diagrams,  and  data  format.  Establishes  and  employs  scien- 
tific programming  techniques  and  flowcharts  for  computer  programs 
to  include  selection  and  interfacing  of  executive  control  and  operating 
routines.  Designs,  develops,  and  employs  data-  and  error-reporting 
procedures,  and  test  and  evaluation  procedures,  and  conducts  tests 
to  ensure  proper  integration. 

• Directs  HOL  analysis  activities  - Directs  the  acquisition,  develop- 
ment, operation,  and  maintenance  of  HOL  development  and  mainte- 
nance. Confers  with  Air  Force  and  other  agencies  concerned  with 
HOL  software  development.  Coordinates  and  consults  with  manu- 
facturer's representatives  concerning  design  and  development  of 
computer  equipment  and  programs.  Conducts  studies  and  recom- 
mends changes  in  component  units  of  compilers  and  application  pro- 
grams to  ensure  maximum  efficiency-  Remains  conversant  with 
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state-of-the-art  developments,  current  Air  Force  and  DOD  standards, 
and  improved  techniques  of  on-line  programming,  computer  utiliza- 
tion, information  retrieval,  and  data  acquisition. 

t 

5.  1.  2.  2.  3 Qualifications 

A bachelor's  degree  in  scientific  or  related  discipline,  with  in-depth  knowledge 
of  capabilities,  limitations,  performance,  and  application  of  HOL  and  com- 
pilers used  in  support  of  Air  Force  projects.  Must  have  at  least  one  year  of 
experience  in  a specific  HOL  to  be  controlled  at  the  LCF;  experience  with  one 
other  primary  HOL  such  as  FORTRAN,  COBOL,  J-3,  J73-I,  J3B,  PL/I, 

ALGOL  or  ATLAS  is  highly  desirable.  The  educational  and  experience  background 
must  demonstrate  a thorough  understanding  and  working  knowledge  of  HOLs  and 
compilers,  and  familiarity  with  each  of  the  primary  HOLs  specified  earlier. 

At  least  one  year  of  this  background  must  include  directing  and  supervising  other 
analysts  and  programmers  on  complex  computer  systems  projects  that  required 
estimating,  evaluating,  and  scheduling  project  workloads.  Experience  in  commu- 
nications languages  is  highly  desirable. 

5.  1.  2.  3 High-Order  Language  Programmer 

5.  1.  2.  3.  1 Job  Summary 

The  High-Order  Language  Programmer  plans,  designs,  develops,  modifies, 
installs,  documents,  and  tests  computer  programs  and  language  compilers,  for 
high-order  programming  languages;  coordinates,  conducts,  and  directs  the 
maintenance  and  modification  of  these  programs  and  assists  the  Programming 
Language  Analyst  in  planning,  analyzing,  estimating,  and  designing  modifications 
to  HOLs. 
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• Designs  programs  - Interprets  systems  design  and  establishes  pro- 
gram logic,  coding  techniques,  and  data  formats  for  programming 
packages  for  HOLs  and  supporting  programs.  Determines  organiza- 
tion and  content  of  data  files,  tables,  records,  and  items. 

• Performs  program  coding  - Prepares  appropriate  computer  instruc- 
tions according  to  program  design,  flow  charts,  and  specifications. 

• Conducts  program  testing  and  modification  - Tests  programs  on 
equipment  and  compares  results  with  program  design  specifications. 
Integrates  component  programs  into  complete  systems  and  operates 
the  system  with  simulated  or  live  data  to  ensure  program  interaction 
according  to  systems  design  and  test  specifications.  Makes  required 
changes  or  modifications  to  programs  as  dictated  by  test  results. 

• Modifies  and  refines  HOL  compilers  - Corrects  errors  and  makes 
changes  to  reflect  program  improvements  and  responds  to  changes 
in  the  operational  environment  or  system  equipment  as  directed. 
Maintains  and  updates  program  documentation.  Assists  and  con- 
ducts studies  as  required  to  determine  need  for,  and  feasibility  of, 
system  improvements. 

• Installs  and  implements  compilers  - Implements  compiler  programs 
in  an  operational  environment  and  conducts,  supervises,  or  pre- 
pares on-site  tests  with  live  data  to  determine  conformance  to 
design  specifications.  Makes  required  changes  as  indicated  by  test 
results. 
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Coordinates  and  directs  programming  activities  - Assigns  pro- 
gramming and  coding  tasks  and  provides  on-the-job  training. 

Estimates  program  production  cost  in  manpower,  development  time, 
and  computer  time.  Coordinates  personnel,  equipment,  and  facility 
requirements  to  meet  programming  commitments.  Develops  and 
improves  programming  procedures  and  standards,  maintains  pro- 
duction controls,  and  reports  progress  in  meeting  objectives. 

5.  1.  2.  3.  3 Qualifications 

This  position  requires  a bachelor's  degree  in  a scientific  or  related  discipline 
and  at  least  four  years  of  programming  experience  with  at  least  three  of  these 
years  engaged  in  the  programming  or  design  of  compilers  and  at  least  one  year 
of  experience  with  an  HOL  compiler.  Six  months  experience  or  more  with  the 
particular  LCF  compiler  assignment  is  mandatory.  Additional  HOL  experience 
is  desirable.  Completion  of  special  training  or  study  in  the  field  of  HOLs  may 
be  substituted  for  the  specific  degree  specialization  for  an  applicant  with  a degree 
in  a nonscientific  or  related  discipline. 

5.  1.  2.  4 Documentation  Specialist 

5.  1.  2.  4.  1 Job  Summary 

The  Documentation  Specialist  maintains,  upgrades,  interprets,  and  develops 
documentation  for  HOLs  and  compilers;  documents  test  results,  compiler 
recommendations,  and  special  studies;  prepares  user  manuals  and  training 
materials;  and  compiles,  edits,  and  publishes  the  LCF  newsletter. 

5.  1.  2.  4,  2 Duties  and  Repons ibilities 

The  Documentation  Specialist  assumes  the  duties  and  responsibilities  described 
below; 

• Develops,  maintains,  interprets,  and  upgrades  HOL  documentation 
using  a working  knowledge  of  HOL  and  computer  systems  concepts 
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to  generate  readable,  clear,  complete,  and  concise  documentation. 
Analyzes  and  researches  compiler  problems  and  existing  documenta- 
tion to  clarify  compiler  capabilities  and  user  requirements. 

Schedules  and  coordinates  documentation  workload. 

• Prepares  compiler  manuals  and  instructions  that  describe  the  use  of 
HOLs,  the  compiler  programming  documentation,  training  pro- 
cedures, and  reference  material. 

• Organizes  and  edits  documentation  of  formal  test  results  and 
installation  requirements. 

• Prepares  documentation  of  special  studies  as  required. 

• Compiles,  edits,  and  publishes  compiler  information,  problems, 
useful  tips,  and  pending  change  applications  in  an  LCF  newsletter 
for  LCF  users,  and  applicable  interested  parties. 

5.  1.  2.  4.  3 Qualifications 

The  Documentation  Specialist  must  have  a degree  in  a scientific  or  related 
discipline  or  a degree  in  English,  technical  communications,  or  related  field 
with  completion  of  computer  science  courses.  Two  years  of  programming 
experience  or  one  year  of  systems  programming  experience  is  mandatory.  Some 
experience  involving  HOLs,  compilers,  control  or  executive  programs  is  manda- 
tory, where  the  quality  of  the  experience  is  more  important  than  the  quantity. 
Experience  with  the  specific  LCF  HOL  or  one  or  more  of  the  primary  HOLs  such 
as  FORTRAN,  COBOL,  J73-I,  J3-B,  PL/1,  ATLAS,  or  ALGOL  is  most 
desirable. 

Past  experience  must  have  demonstrated  the  ability  to  organize,  compile,  write, 
and  edit  complex  computer  systems  data,  to  work  independently,  and  to  produce 
clear  and  concise  documentation  within  the  required  schedules. 
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5.  1.  2.  5 Data  Processing  Machine  Operator 
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5.  1.  2.  5.  1 Job  Summary 

Prepares  for  operation,  supervises,  and  operates  computer  hardware  and 
peripheral  equipment,  and  telecommunication  equipment.  Trains  others  in  the 
operation  of  computer  hardware.  Schedules  and  coordinates  workloads. 

5.  1.  2.  5.  2 Duties  and  Responsibilities 

The  Data  Processing  Machine  Operator  assumes  the  following  duties  and 
responsibilities: 

• Maintains  operable  status  - Sets  up  equipment  at  the  beginning  of 
each  shift  and  shuts  down  at  the  close  of  each  shift  unless  operating 
in  a multiple-shift  environment  where  he  accepts  or  prepares  shift 
turnover  instructions  as  applicable.  Determines  when  equipment 
is  in  need  of  maintenance,  and  schedules  and  supervises  such 
maintenance,  including  both  preventive  and  emergency  maintenance. 

• Operates  computer  hardware  and  peripheral  devices  - Loads, 
mounts,  operates  devices  and  equipment  such  as  consoles,  keyboards, 
paper  tape,  magnetic  tape,  disk  devices,  teleprocessing  equipment, 
keypunch,  sorters,  etc.  as  applicable.  Communicates  with  system 
operating  control  program  using  standard  job  control  language. 

Sets  up  and  schedules  required  runs;  determines  and  communicates 
operational  status;  recognizes  and  determines  causes  of  malfunctions 
and  takes  appropriate  steps  to  correct  them. 

• Maintains  facility  - Maintains  supply  records  and  assures  adequate 
stock  levels.  Maintains  equipment  records  and  operational 
procedures. 
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• Supervises  data  processing  machine  personnel  as  required  - Assigns 
work  and  reviews  completed  work  for  quality  and  quantity.  Explains 
policy  directives  and  conducts  on-the-job  training.  Provides 
guidance  and  direction  in  processing  computer  runs.  Coordinates 
with  programmers,  analysts,  and  the  LCF  manager. 

5.  1.  2.  5.  3 (Qualifications 

This  position  requires  a high  school  diploma  or  equivalent.  Some  college  is 
desirable.  Experience  in  preparing  computer  runs,  operating  computer  hardware, 
and  scheduling  operations  is  mandatory.  Completion  of  a basic  data  processing 
machine  operator  course  or  equivalent  experience  in  operating  data  processing 
hardware  is  desirable.  Telecommunications  and  remote-job-entry  experience, 
as  well  as  specific  experience  with  the  LCF  hardware  environment,  is  highly 
desirable. 

5.  1.  2.  6 LCF  Librarian 
5.  1.  2.  6.  1 Job  Summary 

The  Language  Control  Facility  Librarian  records  all  incoming  and  outgoing  and 
internal  communications  such  as  Software  Problem  Reports,  Language  Change 
Proposals,  Status  Reports,  CCB  schedules  and  minutes,  compiler  configuration 
status,  and  other  informal  status  inquiries  and  communications  pertinent  to  the 
LCF. 

5.  1.  2.  6.  2 Duties  and  Responsibilities 

The  librarian  is  responsible  for  the  following  items  and  must  perform  the  duties 
outlined  below: 

• Maintain  Status  - Maintains  a log  and  records  all  incoming  requests, 
CCB  actions,  and  final  disposition  of  all  Software  Problem  Reports, 
and  Language/Compiler  Change  Proposals. 
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• Maintain  data  files  - Files  all  SPRs,  LCPs,  CCPs,  Status  Reports, 
and  pertinent  documents  including  programmer  and  operator  reference 
materials,  configuration  status,  reports,  test  results,  installation 
status  reports,  special  reports,  audits,  and  other  pertinent  data. 

• Identify  and  Report  Exceptions  - Notifies  appropriate  personnel  of 
overdue  communications  or  status;  prepares  weekly  status  of  open 
items  and  items  closed  during  the  previous  week;  prepares  CCB 
agenda. 

5.  1.  2.  6.  3 Qualifications 

This  position  requires  a high  school  degree  or  equivalent.  Knowledge  of  data 
processing  hardware  and  software  terminology  is  mandatory.  Completion  of 
basic  data  processing  and  programming  courses  is  desirable.  Some  hardware 
operating  experience  is  also  beneficial. 

5.  1.  2.  7 Secretary 

5.  1.  2.  7.  1 Job  Summary 

The  secretary  reports  to  the  LCF  manager  and  provides  clerical  and  steno- 
graphic support  for  the  LCF  staff;  composes  and  prepares  administrative  com- 
munications; maintains  files;  records  proceedings  of  configuration  control 
board  meetings. 

5.  1.  2.  7.  2 Duties  and  Responsibilities 

The  secretary  performs  the  following  duties  and  assumes  the  responsibilities 
described  below: 

• Take  dictation  using  shorthand,  stenotype;  transcribe  from  these 
sources  or  from  dictating  equipment  - Take  dictation  of  administra- 
tive communications,  reports,  directives,  and  telephone  conver- 
sations. Record  proceedings  of  conferences , staff  meetings,  and 


5-15 


committees  by  shorthand  or  stenotype  machine.  Transcribe,  edit, 
and  type  minutes  and  administrative  and  technical  reports.  Prepare 
summaries  and  extracts  of  transcribed  material.  Prepare  digest 
of  transcripts  of  telephone  conversations.  Prepare  stencils,  ditto, 
offset  masters,  etc.  , for  reproduction. 

• Perform  office  services  - Arrange  appointments  and  conferences; 
prepare  conference  agenda;  receive  and  refer  telephone  calls  and 
visitors;  assist  and  answer  questions  on  office  procedure  and  func- 
tions; extract  information  from  files  or  prepare  briefs  of  corre- 
spondence and  reports;  arrange  for  travel  reservations;  prepare 
travel  orders  and  vouchers;  initiate  follow-up  letters  or  memoran- 
dums; compose  and  complete  replies  to  routine  correspondence: 
segregate  and  route  office  mail  and  administrative  communications; 
consolidate  periodic  reports;  and  review  outgoing  correspondence 
for  adherence  to  style,  format  and  policy.  Requisition  office  supplies, 
repair  services,  or  publications  services. 

• Maintain  reference  and  administrative  communications  files  - Obtain 
material  such  as  stationery/supplies,  reports,  publications  forms, 
and  catalogs.  Assemble  briefs , tabulate,  and  file  information  per- 
tinent to  office  activities.  Examine,  classify,  code,  index,  and 

file  documentation  such  as  correspondence,  messages,  memoranda, 
reports,  publications,  forms,  orders,  schedules,  catalogs,  and 
requisitions,  using  alphabetical,  chronological,  geographical, 
organizational,  subjective,  or  numerical  systems,  and  cross- 
referencing.  Prepare  files  maintenance  and  disposition  forms. 
Establish  and  maintain  tickler,  suspense,  special  data,  and  locator 
files.  Maintain  pertinent  office  technical  publications  for  ready 
reference  and  operational  files.  Post  indexes,  remove  and/or  insert 
changes  to  publications  and  directives.  Receive,  control,  and  file 
security  documents. 
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5.  1.  2.  7.  3 Qualifications 


This  position  requires  a high  school  diploma  or  equivalent  with  courses  in 
business  English,  typing,  shorthand,  and  general  office  administration  desirable. 
Ability  and  knowledge  of  shorthand  or  operation  of  stenotype  or  dictating  equip- 
ment is  mandatory;  skills  must  be  at  a level  to  type  at  a rate  of  50  words  per 
minute  or  more  and  to  take  dictation  at  a rate  of  at  least  90  words  per  minute. 
This  position  requires  a good  knowledge  of  spelling,  grammar,  punctuation,  and 
standard  office  procedures  and  equipment.  Previous  experience  in  functions 
such  as  taking  and  transcribing  dictation  of  official  correspondence  or  recording 
also  is  desirable. 

5.  1.3  MANPOWER  SOURCES 

5.  1.3.  1 Considerations 

The  LCF  must  establish  itself  as  the  most  reliable  and  efficient  means  of  main- 
taining and  improving  existing  compilers.  Audit  procedures  can  determine 
compliance  and  standardization  of  procedures  but  cannot  ensure  cooperation 
and  acceptance.  The  LCF  staff  must  establish  a rapport  with  the  various  HOL 
users  and  within  the  RADC  or  applicable  organization.  There  are  three  possible 
sources  of  personnel  to  staff  the  LCF:  military,  civil  service,  or  Government 
contractor.  It  is  not  necessary  that  only  one  source  be  considered;  however, 
the  optimum  mix  would  preclude  any  duplication  of  sources  for  any  one  job 
position,  and  ideally  would  use  the  same  source  within  job  families.  Adequate 
communications  and  chain  of  command  considerations  affect  the  organizational 
staffing.  The  organizational  operating  cost  and  efficiency,  and  the  personnel 
qualifications  and  continuity  must  be  evaluated  in  order  to  select  the  best 
source.  All  of  these  factors  have  been  considered  in  the  recommendations  that 
follow. 
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The  staffing  study  is  based  on  the  premise  that  the  following  recommendations 
are  adopted: 


• Single  shift  operation 

• Single  operator  hardware  configuration 

• Open  shop  environment  for  operation  of  hardware 

• Pre-established  hardware  operating  procedures 

The  organization  is  divided  into  the  two  logical  functions:  operations  and 
analysis  programming.  Within  these  two  functions  it  is  not  advisable  to  staff 
from  different  sources.  The  management  of  these  functions  must  be  consistent 
with  the  RADC  or  applicable  organizational  structure  and  with  the  staffing  recom- 
mendations for  its  subordinate  LCF  organization.  Therefore  it  is  possible  to 
have  each  of  the  three  sources  represented  within  the  organization,  as  long  as 
the  functional  responsibilities  remain  intact  for  each  of  the  staff  sources. 

5.  1.  3.  2 Relative  Staff  Cost 

The  cost  of  staffing  the  proposed  organization  from  either  of  the  three  possible 
sources  is  based  on  the  following  remuneration  sources: 

• USAF  pay  and  allowance  tables  for  cumulative  years  of  service 

• U.  S.  Civil  Service  Commission  General  Schedule,  October  1975 

• Private  Industry  salaries,  "Weber  Salary  Survey  on  Data  Process- 
ing Positions  in  the  United  States,"  A.  S.  Hanson,  Inc.  , as 
published  in  Datamation,  January  1976,  Volume  22,  Number  1, 

pp.  73-87. 
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The  Air  Force  rates  do  not  include  flight  pay  but  do  include  dependents  in  the 
basic  allowance  for  quarters  (BAQ),  and  the  basic  allowance  for  subsistence 
(BAS).  The  Civil  Service  rates  do  not  presume  the  adoption  of  the  proposed 
1976  pay  raise  of  6 percent.  The  private  industry  rates  used  for  contractors 
do  not  include  composite  indirect  costs  nor  profits.  Estimates  of  these  figures 
can  be  obtained  through  the  Defense  Contract  Administration  Services  (DC AS). 

For  the  purpose  of  this  study,  the  composite  indirect  and  profit  costs  were 
assumed  to  represent  an  increase  of  from  25  to  100  percent  of  the  base  salary. 
This  was  evaluated  in  the  final  consideration,  but  is  not  included  in  the  rates 
quoted  in  this  study.  The  rates  for  each  source  by  equivalent  job  descriptions 
are  shown  in  Table  5-1.  A final  evaluation  can  only  be  made  by  determining  a 
specific  contractor  or  contractors  and  preparing  a Cost  Analysis  Worksheet, 

DA  Form  3207-R,  including  cost  elements  other  than  staffing.  A copy  of  this 
form  is  included  in  Appendix  B. 

5.  1.3.  3 Relative  Staff  Qualifications 

The  qualifications  for  the  key  staff  positions  are  of  utmost  importance.  These 
key  personnel  can  determine  whether  the  LCF  concept  is  a success  or  failure. 

The  remaining  personnel  can  be  classified  as  support  personnel.  Their  job 
descriptions  are  more  general  and  require  a minimum  amount  of  specialized 
background.  Explicit  work  procedures  for  these  support  personnel  ensure  that 
employee  capabilities  are  stressed  rather  than  depth  of  specific  skill  backgrounds. 

The  positions  that  are  designated  as  key  are  shown  in  Table  5-2.  Also  shown 
are  the  support  positions.  Each  is  ranked  as  to  the  estimated  availability  of 
qualified  personnel.  Special  notice  must  be  given  to  the  rankings  for  key 


5-19 


Table  5-1.  Estimated  Annual  Remuneration  by  Source  (1  of  2) 


Source  and  Equivalent  Position  Title* 

■Job  Title 

Air  Force 

Civil  Service 

Private  Industry 

Manager 

Computer  Systems 
Staff  Officer,  AFSC 
5116,  Major  12  yrs. 

Computer 
Specialist,  GS-13, 
Step  1 

Manager,  Systems 
Programming 

$21,214 

$22,906 

$22,620 

Analyst 

Computer  Systems 
Analyst,  AFSC 
5135A, 

Captain  10  years 

System  Analyst, 
GS- 12,  Step  1 

Computer  Systems 
Analyst 

$19,195 

$19,386 

$20, 904 

Programmer 

1 

Computer  Systems 
Programming- 
Officer,  AFSC 
5144A,  Capt.  8 vrs. 

Programmer, 
GS-11,  Step  5 

Senior 

Programmer 

. 1 

$18,391 

$18,423 

$18, 564 

Documentation 

Specialist 

Instructional 
Programming 
Technician,  AFSC 
75173,  M/Sgt.  12  yrs. 

Computer 
Specialist, 
GS-11,  Step  2 

Analyst  A 

$14,025 

$16,797 

$17,004 

Operator 

Data  Processing 
Machine  Operator 
AFSC  68550, 

Sgt.  4 yrs. 

Computer 
Operator, 
GS-6,  Step  1 

Computer 
Operator  A 

$9,223 

$9,946 

$9,880 

Does  not  include  indirect  loading  factors,  as  applicable. 


f 
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Table  5-1.  Estimated  Annual  Remuneration  by  Source  (2  of  2) 


Source  and  Equivalent  Position  Title* 

LCF  Organization 
Job  Title 

Air  Force 

Civil  Service 

Private  Industry 

Librarian 

Data  Services 
Specialist,  AFSC 
68  150,  Sgt.  4 yrs. 

Computer 
Technician, 
GS-5,  Step  4 

Data  Control 
Clerk  A 

$9,223 

$9,819 

$8,944 

Sec retary 

Stenographic 
Specialist,  AFSC 
70450,  Sgt.  2 yrs. 

Clerk  - 
Stenographer 
(Secretary) 
GS-4,  Step  4 

Secretary, 
Class  B 

$8,671 

$8,774 

$9,  100 

Organization 

Total 

$99,942 

$106,051 

$107,016 

Does  not  include  indirect  loading  factors,  as  applicable. 


Table  5-2.  Qualification  Rankings  by  Source 


Good  specific  qualifications  readily  available 
Excellent  specific  qualifications  readily  available 


personnel  as  the  rankings  do  not  reflect  capabilities  of  personnel  as  do  those 
for  the  support  personnel.  Rather,  these  rankings  reflect  the  availability  of 
specific  skill  levels  among  a range  of  capable  management  level  of  personnel 
within  each  of  the  three  recognized  source  structures. 

There  is  a noticeable  disparity  between  the  ranking  of  a staff  composed  of  all 
Air  Force  personnel  and  staffs  composed  totally  of  either  contractor  or  Civil 
Service  personnel.  Upon  closer  examination  it  is  shown  that  this  disparity 
results  from  the  relative  ranking  of  the  key  personnel  requiring  specialized 
skills.  The  specific  experience  in  developing  HOLs,  specifically  a long-term 
experience  in  a particular  language,  is  not  as  readily  available  in  the  services 
where  personnel  change  assignments  frequently.  The  same  disparity  is  shown 
between  civil  service  and  contractor  personnel  in  the  key  personnel  positions. 
This  is  attributed  to  the  presence  in  private  industry  of  personnel  with  the 
specific  HOL  experience,  and  background  in  its  development,  for  the  initial 
installation  considered  in  this  study. 

However,  the  most  qualified  personnel  for  a variety  of  HOLs  may  not  be  avail- 
able from  a single  contractor.  If  more  than  one  contractor  is  to  be  considered, 
the  organizational  structure  and  efficiency  would  be  unduly  impacted. 

5. 1.3.4  Recommended  Organization  Sources 

Evaluating  the  data  previously  presented  and  considering  future  growth  potential 
of  the  organization,  the  following  sources  of  personnel  to  staff  the  facility  are 
recommended.  Justification  for  each  recommendation  is  included. 

The  key  personnel,  consisting  of  the  LCF  manager,  the  analyst,  the  program- 
mer, and  the  documentation  specialist,  must  be  able  to  be  committed  to  the 
project  for  an  extended  period  of  time.  Salaries,  unless  prohibitive,  are  of 
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lesser  importance.  The  conclusion  drawn  from  the  data  gathered  and  presented 
in  this  study  indicates  that  the  most  qualified  programmers  and  analysts  are 
available  from  Government  contractors  with  equally  qualified  managers  and  docu- 
mentation specialists  in  civil  service  or  private  industry.  However,  considering 
overall  organizational  structure  and  efficiency  of  operation,  it  is  not  recommended 
that  a branch  of  the  organizational  tree  contain  mixed  personnel.  Efficiency  of 
operation  is  enhanced  when  personnel  are  working  for  the  same  organization  to 
which  they  answer.  It  is  recommended  that  all  of  the  key  personnel,  the  man- 
ager, analyst,  programmer,  and  documentation  specialist,  be  Civil  Service 
personnel.  Their  qualifications  are  rated  highly,  the  cost  is  competitive  with 
contractor  costs,  and  greater  continuity  of  service  can  be  guaranteed  than  with 
either  of  the  other  sources.  For  the  purposes  of  this  study,  the  LCF  organiza- 
tion will  be  able  to  operate  efficiently  and  compatibly  with  the  related  RADC 
organization  and  yet  will  have  independence  from  the  user  organizations. 

The  support  personnel  qualifications  are  evenly  distributed  among  the  three 
sources.  Continuity  is  much  less  a factor  here  because  complete  operating 
procedures  will  be  available  and  the  requirement  for  specific  progressions, 
skills,  training,  and  education  are  not  as  great.  Therefore,  the  least-expensive 
source  deserves  consideration  if  it  is  consistent  with  the  general  organizational 
efficiency.  The  recommended  staffing  for  the  support  positions  is  to  use  Air 
Force  personnel  for  the  operator  and  librarian  positions  but  to  use  a Civil 
Service  secretary  because  a more  efficient  relationship  will  result. 

The  resulting  organization,  as  reflected  in  the  chart  shown  in  Figure  5-2,  is 
an  independent  Civil  Service  group  reporting  to  a commanding  officer,  with 
the  Operations  Section  comprising  Air  Force  personnel  and  the  Programming 
and  Analysis  Section  comprised  of  civil  service  personnel.  This  group, 
although  independent  of  existing  language  groups  such  as  RADC's  Information 
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Figure  5-2.  LCF  Organization  Chart 
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Sciences  HOL  group,  should  work  closely  with  such  groups  regarding  current 
applications,  language  developments,  and  the  Configuration  Control  Board. 
Additional  meetings,  correspondence,  and  discussions  should  be  encouraged 
within  the  LCF  so  that  the  staff  does  not  become  so  bogged  down  with  mainte- 
nance and  auditing  that  it  fails  to  provide  leadership  and  direction. 

The  recommended  organizational  structure  is  careful  to  differentiate  between 
the  different  kinds  of  positions  and  the  aptitude  and  characteristics  of  personnel 
usually  filling  such  positions.  Thus,  the  analytical  and  creative  positions  are 
not  restricted  by  the  clerical  functions  or  the  operational  requirements  of  the 
organization.  Likewise,  the  operational  and  clerical  functions  are  separate 
from  the  problem  solving  functions.  The  resulting  efficiency  is  greatly  increased 
as  the  complexity  of  the  HOL  or  the  number  of  HOLs  to  be  controlled  increases. 

5.2  FACILITY  DESIGN 

Facilities  planning  often  takes  a back  seat  to  selection  of  computer  equipment, 
system  and  software  design,  and  other  activities.  Facility  siting  issues 
are  frequently  slighted  until  a problem  becomes  evident  after  the  system  is 
operational.  Unfortunately,  post-installation  solutions  are  more  expensive 
and  riskier  once  operations  begim  Therefore,  the  importance  of  proper  and 
early  facility  design  should  not  be  underestimated. 

Traditionally,  problems  that  designers  encounter  when  planning  a new  computer 
facility  include: 

• Specifying  power  and  air  conditioning  requirements  for  the 
facility  in  the  evaluation  stage 

• Selecting  an  economical  and  reliable  auxiliary  power  generating 
system 

• Deciding  to  use  overhead  or  underfloor  air  conditioning 

• Designing  grounding,  static  electricity,  and  acoustics  systems 
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As  can  be  seen  from  this  list  of  problems,  design  of  a computer  facility  is  no 
trivial  task.  However,  in  the  case  of  the  LCF  design,  which  is  based  on  the 
use  of  computer  terminals  rather  than  a free-standing  computer  system,  the 
anticipated  problems  are  less  severe  and  are  of  a different  type.  With  com- 
puter terminals  the  requirements  for  overhead  air  conditioning  and  a primary 
power  source  are  still  valid.  However,  the  requirements  for  underfloor  air 
conditioning,  auxiliary  power  system,  and  an  acoustics  system  simply  do  not 
apply.  Also,  no  special  equipment  or  grounding  system  (such  as  a system 
ground  plate  or  a copper  grid  system)  is  required. 

The  design  of  the  LCF  facility,  therefore,  focuses  upon  the  following 
considerations : 

• Equipment  definition 

• Facility  floor  space  and  layout 

• Air  conditioning 

• Power 

• Maintenance 

• Consumables 

An  assumption  made  in  this  study  is  that  the  LCF  will  be  located  either  adjacent 
to  or  very  near  the  present  RADC  computer  facility  (i.  e.  , the  H-6080  and 
H-6180  facility)  or  similar  organization.  Accordingly,  it  was  assumed  that  com- 
puter support  services  such  as  keypunch,  card-to-magnetic  tape,  and  magnetic- 
tape-to-card  operations  would  be  available  at  the  computer  facility  equipment. 

5.  2. 1 EQUIPMENT  DEFINITION 

5.  2. 1. 1 Terminal  Equipment 

Computer  terminals  recommended  for  the  LCF  consist  of  two  GE  Terminet-300 
(or  equivalent)  teletypewriter  terminals.  Both  of  these  terminals  should  be 
dedicated  terminals,  plug  connected  to  the  Automatic  Line  Control  logic  (refer 
to  Figure  3-2).  One  terminal  will  communicate  with  the  H-6080  GCOS  system 
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and  the  other  with  the  H-6180  MULTICS  system  and  the  ARPA  TIP.  In  this 
configuration,  backup  of  each  terminal  can  be  provided  by  the  other  terminal. 
Also,  the  proximity  of  one  terminal  to  the  other  will  permit  single-operator 
utilization  in  any  of  the  LCF  data  processing  functions. 

5.  2. 1.  2 Office  Equipment 

The  office  equipment  requirements  for  the  LCF  include  telephone  services, 
typewriters,  document  reproduction  equipment,  and  office  fixtures. 

Telephone  services  for  seven  personnel  locations  must  be  provided.  These 
locations  are:  the  LCF  manager's  office,  secretary's  office,  two  language 
analysts'  offices,  document  center,  operations  room,  and  the  library.  In  addi- 
tion, one  "hotline"  telephone  to  be  used  only  for  communication  with  the  users 
should  be  installed  in  a location  easily  accessible  to  the  teletypewriter 
terminals. 

Typewriters  will  be  required  in  at  least  three  LCF  offices;  one  at  the  desk  of 
the  secretary  to  the  LCF  manager,  one  in  the  document  center,  and  one  in  the 
library. 

With  the  amount  of  documentation  reproduction  and  distribution  to  be  performed 
by  the  LCF,  proprietary  document  reproduction  equipment  is  considered  essen- 
tial. This  document  reproduction  equipment  should  include  the  following  fea- 
tures: computer  printout  form  and  letter-size  paper  feed,  and  multiple  levels 
of  copy  size  reductions. 

Sufficient  office  fixtures  to  support  the  personnel  requirements  (7  persons) 
recommended  for  initial  staffing  of  the  LCF  must  be  provided.  Also  a con- 
ference table  and  chairs  will  be  required  to  accommodate  LCF  change  control 
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board  meetings  in  the  facility.  The  estimated  quantities  for  each  furniture 
item  are: 


Item  Quantity 

Desk  9 

Desk  Chairs  13 

Waste  Baskets  9 

Conference  Table  1 

Conference  Chair  8 

Table  (Operations  Room)  2 

Chalkboard  7 

Status  Board  4 

File  Cabinet  7 

Document  Cabinet  8 

Punch- Card  Cabinet  4 


5.  2.  2 FACILITY  FLOORSPACE 


A typical  floor  plan  layout  for  the  LCF  is  shown  in  Figure  5-3.  This  floor  plan 
allows  for  some  office  space  expansion  and  provides  the  following  features : 


• LCF  manager's  office  centrally  located  to  all  subordinate  office 
functions,  and  to  conference  room 

• Conference  room  facilities  comfortably  seating  eight  people 

• Individual  adjoining  offices  for  the  language  analysts 

• LCF  manager's  secretary  located  close  to  primary  typing 
sources  (i.  e.  , LCF  manager,  documentation  specialist,  and 
language  analysts) 


5.  2.  3 AIR  CONDITIONING 


It  is  assumed  that  an  overhead  air  distribution  system  will  be  used  for  the 
facility.  In  this  type  of  system,  air  is  supplied  into  an  overhead  plenum,  and 
from  there  it  is  pumped  down  through  the  ceiling  and  dispersed  into  the  rooms 


1 


1 
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to  provide  the  required  ambient  temperature.  Using  this  type  of  air  distribution 
system,  and  based  on  the  use  of  non-temperature-critical  equipment,  an  accurate 
approximation  of  the  air  conditioning  capacity  required  for  the  LCF  can  be  made 
based  on  the  following  heat  exchange  factors : 

• Each  Kw  of  equipment  power  consumption  results  in  3413  BTU 
per  hour  heat  load 

• Assuming  standard  construction  materials  and  one  air  change 
per  hour  ventilation,  the  other  heat  sources  (i.  e.  , lighting, 
outside  air,  conduction,  radiation,  etc. ) can  be  estimated  to 
be  30  BTU  per  hour  for  each  square  foot  of  floor  space 

• The  heat  output  from  people  can  be  assumed  to  average  300  BTU 
per  person  per  hour 

• 10  percent  contingency  is  added  to  account  for  fan  energy,  duct 
losses , and  leakage 


• 10  percent  is  added  to  account  for  latent  gains 

Using  the  above  factors,  the  estimated  total  heat  load  of  the  LCF  is  as  folio, vs : 


Source 

Heat  Load  (BTU) 

Equipment: 

2 TTY  Terminals  (35%  load  time) 

6,681 

3 Typewriters  (35%  on  time) 

5,364 

1 Document  Reproducer  (30%  load  time) 

12,013 

Overhead  Sources  (2042  x 30) 

61,260 

Personnel  (7  x 300) 

2,100 

Subtotal 

87,418  (BTU) 

10%  Contingency  (for  fan  energy  duct  losses,  and  leakage) 

8,742 

10%  Latent  Heat  Gain 

8,742 

TOTAL 

104,902  (BTU) 
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The  resultant  estimated  air  conditioning  tonnage  (104,8  2 8 divided  by  12,000) 
required  for  the  LCF  is  approximately  9 tons. 

5.  2.  4 POWER 

Utility  source  60-HZ  electrical  power  can  be  used  throughout  the  facility. 
The  estimated  power  requirements  for  the  LCF  are  itemized  as  follows: 


User 

Power  Requirement  (KW) 

Terminal  Equipment 

3.45 

Typewriters 

4.49 

Document  Reproducer 

6.  60 

Lighting 

6.  13 

Airconditioning /Heating 

6.  71 

TOTAL 

27.  38  (KW) 

A typical  monthly  power  consumption  estimate  (based  on  a single-shift  176-hour 
month)  for  the  LCF  is  shown  below: 


User 

Power  Consumption  (KWH) 

Terminal  Equipment  (35%  load  time) 

344 

Typewriters  (35%  on  time) 

276 

Document  Reproduction  (30%  load  time) 

620 

Lighting 

1,618 

Airconditioning  and  Heating 

3,543 

Subtotal 

6,401  (KWH) 

20%  Compensation  (for  peak  loading) 

1,280 

TOTAL 

7,681  (Typical  Month) 
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5.2.5  MAINTENANCE 


Maintenance  of  the  facility  will  require  support  resources  in  two  areas:  (1) 

equipment  maintenance  and  (2)  building  maintenance.  It  was  assumed  that  the 
LCF  would  be  located  at  RADC  and  that  no  construction  or  rental  costs  would 
be  incurred.  Building  maintenance  can  be  provided  by  maintenance  personnel 
and  equipment  resources  currently  existing  at  RADC.  Since  maintenance  of 
the  facility  building  is  to  be  performed  by  currently  existing  maintenance  pro- 
cedures, personnel,  and  equipment,  further  definition  of  these  requirements  is 
felt  to  be  outside  the  scope  of  this  study.  The  second  type  of  maintenance, 
equipment  maintenance,  can  be  performed  either  by  RADC  maintenance  resources, 
or  by  the  vendors  supplying  the  equipment.  The  equipment  requiring  preventive 
and  corrective  maintenance  are:  two  teletypewriter  terminals,  three  typewriters, 
and  one  document  reproducer. 

5.  2.  6 CONSUMABLES 

Consumable  items  for  the  LCF  include  office  supplies,  equipment  supplies, 
and  the  HOL  reports  and  forms  identified  elsewhere  in  this  report.  Office 
supply  stock  includes  such  things  as  typing  paper,  writing  pads,  erasers,  pens 
and  pencils,  paper  clips,  staplers  and  staples,  rubber  bands,  hardbound  notebook 
binders,  etc.  Equipment  supply  stock  includes  such  things  as  typewriter  ribbons, 
teletypewriter  paper  and  paper  tape,  and  copier  paper.  Spare  equipment 
parts  can  best  be  supplied  as  required  by  the  vendor  or  equipment  maintenance 
source.  The  HOL  report  stock  includes  software  problem  reports,  status 
report,  language/compiler  change  proposal,  and  language  statistics  report. 


5.3  FACILITY  COSTS 

5.  3. 1 GENERAL  DESCRIPTION 


Facility  costs  are  summarized  in  Table  5-3.  In  the  summary  a total  of  eleven 
cost  elements  are  included,  and  the  application  of  each  cost  element  to  one  or 
more  of  the  three  systems  stages  is  shown.  Descriptions  of  each  of  the  cost 
elements  are  given  in  the  following  subsections. 

5.  3. 1.1  Computer  System  Hardware 

The  cost  elements  in  this  category  are:  system  enhancement,  communications 
interface,  and  terminal  devices.  Systems  enhancement  refers  to  the  cost  of  host 
computer  hardware  capability  expansion  required  for  hosting  the  LCF.  These 
expansions  include  such  things  as  an  additional  main  memory  module  or  an  addi- 
tional disk  drive  unit.  Communications  interface  refers  to  the  cost  of  host  com- 
puter hardware  additions  or  modifications  required  to  interface  the  host  computer 
with  the  communications  network.  An  example  would  be  the  addition  or  modifi- 
cation of  an  I/O  channel  controller.  Terminal  devices  refers  to  the  cost  of 
terminal  devices  to  be  installed  in  the  LCF  and  the  users'  facilities. 

5.  3. 1.2  Communications  Network 

The  cost  elements  in  this  category  are:  network  configuration,  computer  inter- 
face devices,  and  network  use  charges.  Network  configuration  refers  to  the  cost 
of  adding  a new  user  to  the  communications  network,  i.e. , nodal  equipment  costs 
divided  by  the  number  of  users.  Computer  interface  devices  refers  to  the  cost 
of  communications  nodal  equipment  hardware  modifications  required  to  interface 
with  a new  host  computer,  i.  e. , specialized  HOST-TIP  interface  hardware.  Net- 
work use  charges  are  the  cost  of  using  the  communications  network.  In  the 
ARPANET  the  use  charge  is  a fixed  annual  rate  rather  than  being  based  on  inter- 
nodal  traffic  quantities . 


5. 3. 1.3  Software  Components 

The  cost  elements  in  this  category  are:  installation  of  existing  packages, 
adaptation/modification  of  software,  new  software  development,  and  software 
enhancement.  These  cost  elements  collectively  address  the  software  costs  of 
the  three  different  types  of  software  required:  LCF  software  tools,  program 
development  support  software,  and  the  ARPANET  protocol  packages.  Installa- 
tion of  existing  packages  relates  to  installation  of  existing  LCF  software  tools. 
Adaptation/modification  of  software  relates  to  each  of  the  three  types  of  software 
required.  New  software  development  relates  to  the  LCF  software  tools.  Soft- 
ware enhancement  refers  to  software  improvements,  which  perhaps  are  not  man- 
datory for  installation  in  the  initial  implementation  of  the  LCF,  but  are  extremely 
desirable  in  terms  of  increased  operational  capabilities.  It  is  recommended  that 
these  software  improvements  either  be  incorporated  in  the  initial  implementa- 
tion of  the  LCF,  or  as  shortly  thereafter  as  is  possible.  These  software 
improvements  relate  to  both  the  LCF  software  tools  and  the  program  develop- 
ment support  software. 

5. 3. 1.4  Manpower 

This  single  cost  element  refers  to  operating  personnel  costs. 

5.3.2  DETAILED  BREAKDOWN  OF  COST  ELEMENTS 
5. 3. 2.1  System  Development 

All  of  the  cost  elements  identified  in  Table  5-3,  with  the  exception  of  network  use 
charges  and  operational  staff  costs,  apply  to  this  stage  of  the  system.  The  break- 
downs for  each  of  the  applicable  cost  elements  follow: 

• System  Enhancement.  This  cost  element  is  not  required  in  the 
initial  implementation  of  the  LCF,  nor  in  foreseeable  expansions 
to  the  LCF. 

• Communications  Interface.  Likewise,  this  cost  element  is  not 
required  in  the  initial  implementation  of  the  LCF. 
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• Terminal  Devices.  The  terminal  equipment  selected  for  the  LCF 
are  two  GE  Terminet-300  teletypewriters.  The  estimated  cost  of 
these  terminals  is  $6,000  to  $6,200  each.  It  is  anticipated  that 
the  addition  of  a second  HOL  to  the  LCF  will  require  that  a third 
terminal  be  added  to  the  facility. 

• Network  Configuration.  This  cost  element  is  not  applicable  to  the 
LCF,  it  does,  however,  apply  to  each  user  (providing  that  the  user 
is  not  currently  using  the  ARPANET).  This  cost  is  prorated  based 
on  the  number  of  (TIP)  users  connected  to  a TLt',  i.e. , $100,000 
divided  by  the  number  of  TIP  users. 

• Computer  Interface  Devices.  Likewise,  this  cost  element  does  not 
apply  to  the  LCF,  but  does  apply  to  each  user  not  currently  using 
the  ARPANET.  The  cost  figure  is  $10,000  to  $15,000  per  user. 

• Installation  of  Existing  Packages.  Three  of  the  required  LCF  soft- 
ware tools  (JCVS,  JOCIT  and  JAVS)  can  be  used  as  they  are  pres- 
ently configured  under  GCOS. 

• Adaptation  or  Modification  of  Software.  This  is  the  largest  cost  ele- 
ment for  implementation  of  the  LCF.  It  includes  the  following  costs: 


Software 

Costs 

JLMT 

28-62  Man-months 

Host  Support 

SYMPL 

6-9  Man-months 

Obj.  Link- Load 

20-30  Man-months 

Debugging 

24-36  Man-months 

Lang.  Translator 

3-24  Man-months 

1 


Host-ARPANET 

Interface 


TOTAL 


6-12  Man-months 
87-173  Man-months 


New  Software  Development.  This  cost  element  relates  to  develop- 
ment of  language  specification  software  support  material.  It 
includes  the  following  costs: 


Software 

Costs 

Standard  HOL  Reference 

6 Man-months 

Tutorial  Text 

18-24  Man-months 

Teaching  Guide 

8-12  Man-months 

Supplementary  Materials 

18-22  Man-months 

TOTAL 

50-64  Man-months 

Software  Enhancement.  This  cost  element  has  a two-fold  applica- 


tion. The  first  is  the  software  enhancement  required  to  signifi- 
cantly improve  the  initial  operational  capability  of  the  LCF.  This 
includes  the  following  costs: 


Software 

Costs 

Enhancement  for  retargeting  JOCIT 
Code  Straightening 
Dead  Variable  Analysis 

30*  Man-months 

Extended  Loop  Optimizations 

<13*  Man-months 
1 8 Man-months 

Parallel  Path  Optimizations 
Use  of  COMPOOL  by  the  Optimizer 
Miscellaneous  Optimization 
Source  Module  Text  Editing 

18  Man-months 

Automated  Code  Generation 

36-48*  Man-months 

JCVS 

6-12  Man-months 

TOTAL 

(111-129MM)  -(79-91MM)  = 
32-38  Man-months 

♦These  modifications  are  currently  being  performed  or  are  anticipated  to  be  per- 
formed on  other  RADC  contracts. 


The  second  application  of  this  cost  element  is  the  software  enhance- 
ment, or  improvements,  recommended  to  accommodate  the  addition 
of  new  HOLs.  The  costs  shown  below  reflect  the  generalized  soft- 
ware tool  recommendations  described  in  Volume  2 of  this  report. 


Software 

Costs 

JOCIT  (generalize) 

6-15  Man-months 

JOCIT 

12-36  Man-months 

Reformatted  Source 

Text 

6-9  Man-months 

Language  Spec,  (each  new  HOL) 

6-12  Man-months 

Program  Validation 

29-36  Man-months 

Statistics  Collection 

28-62  Man-months 

Language  Translator 

6-12  Man-months 

JCVC 

29-36  Man-months 

TOTAL 

122-218  Man-months 

Summation.  The  sum  of  the  cost  elements  applying  to  the  system 
development  stage  of  the  LCF  are  shown  below: 


Facility 

Single  HOL 

Addition  of  Second  HOL 

LCF 

169-275  Man-months 

122-218  Man-months 

+ 

+ 

$ 12,000  - $12,400 

$6,000  - $6,200 

Each  User 

$ 6,000  -$  6,200 
+ 

$100,000  divided  by  num- 
ber of  TIP  users 

+ 

$ 10,000  - $15,000 

None 

5. 3. 2. 2 System  Operation 

The  following  cost  elements  apply  to  the  operational  stage  of  the  system:  office 


equipment,  network  use  changes,  and  operational  staff.  The  breakdowns  for  each 
of  the  cost  elements  follow: 

0 Office  Equipment.  This  cost  appears  under  the  "Terminal  Devices" 
cost  element  in  Table  5-3.  It  does  not  relate  to  terminal  device 
equipment,  but  instead  refers  to  rental  costs  of  the  three  type- 
writers - $1, 080/year  and  the  document  reproduce  - $4, 020 /year. 

• Network  Use  Charges.  This  cost  element  is  applicable  to  both  the 
LCF  and  the  user.  The  charge  for  using  the  ARPANET  is  a fixed 
annual  charge  of  $60,000. 

• Manpower.  This  cost  element  refers  to  the  operational  staff  per- 
sonnel costs  identified  in  Section  4 of  this  volume.  These  include 
the  following: 


Staff  Member 

Costs1 

LCF  Manager 

$ 22,906 

Secretary 

$ 8,774 

Analyst 

$ 19,386 

Programmer 

$ 18,423 

Documentation  Specialist 

$ 16,797 

Operator 

$ 9,223 

Librarian 

$ 9.223 

TOTAL 

$104,732 

1 


Does  not  include  indirect  loading  factors,  as  applicable. 
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Operational  staff  additional  estimates  for  controlling  a second  HOL 
from  a single  LCF  includes  the  following  manpower: 


Staff  Member 


Costs 


1 


Analyst 

Programmer 


TOTAL 


$19,386 

$18,423 

$37,809 


• Summation.  The  sum  of  the  cost  elements  applying  to  the  system 
operation  stage  of  the  LCF  is  shown  below: 


Facility 

Single  HOL 

Addition  of  Second  HOL 

LCF 

$65,500  + $104, 7001 

$37,8001 

Each  User 

$60, 000/year 

None 

5. 3. 2. 3 Maintenance 

The  following  cost  elements  apply  to  this  stage  of  the  system:  terminal  devices, 
installation  of  existing  software  packages,  adaptation/modification  of  software, 
and  new  software  development.  The  breakdowns  for  each  of  these  cost  elements 
follow: 

• Hardware.  This  cost  element  includes  hardware  maintenance  of  the 
two  teletypewriter  terminals  (and  the  three  typewriters  and  docu- 
ment reproducer): 


Hardware  Item 

Single  HOL 

Addition  of  Second  HOL 

Teletypewriter  Terminals  (2) 

$1,500 

(1)  $750 

Typewriters  (3) 

$ 180 

None 

Document  Reproducer 

$2,220 

None 

TOTAL 

$3, 880/year 

$750/year 

^Does  not  include  Indirect  loading  factors,  as  applicable. 
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• Software  Maintenance.  Three  software  component  elements  will 
require  continuing  maintenance.  This  requirement  is  four  to  five 
programmers  working  full  time  in  maintenance  of  a single  HOL. 

• Summation.  The  sum  of  the  annual  cost  elements  applying  to  system 
maintenance  for  the  LCF  is  shown  below: 


Facility 

Single  HOL 

Addition  of  Second  HOL 

LCF 

48-60MM(Systems 

48-60MM  (Systems 

Programming) 

Programming) 

$3, 880 /year 

$7 50 /year 

Each  User 

$750/year 

None 

5.3.3  LCF  MONTHLY  OPERATION  AND  MAINTENANCE  COST'i 
5.3.3. 1 Single  HOL 

The  estimated  monthly  operation  and  maintenance  costs  for  an  LCF  controlling  a 
single  HOL  are: 

Operation:  $5, 458  + $8,  725* 

Maintenance:  4-5  Man-months  (Systems  Programming)  + $324 
5. 3. 3.  2 Addition  of  Second  HOL 

The  estimated  additional  monthly  operation  and  maintenance  costs  are: 
Operation:  $3, 150* 

Maintenance:  4-5  Man-months  (Systems  Programming)  + $63 


1 


Does  not  Include  Indirect  loading  factors,  as  applicable. 
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SECTION  6 - MULTIPLE  HOL  CONTROL 


6.1  ANALYSIS 

While  this  study  has  determined  the  feasibility  of  an  independent  language  control 
facility  for  controlling  language  modifications,  the  issues  of  how  many  languages 
are  to  be  controlled  at  a single  facility,  or  how  many  facilities  are  required, 
must  be  addressed.  The  objectives  to  be  considered  are  effectiveness,  operating 
efficiency,  accessibility,  and  cost. 

6. 1. 1 SINGLE  LCF  CONTROLLING  MULTIPLE  HOLs 

Some  of  the  problems  to  be  considered  in  operating  a single  LCF  site  for  multiple 
HOLs  are: 

• Communications  requirement 

• Hardware  requirement 

• Staffing  impact 

• Physical  facility  requirement 

• Accessibility  to  the  user 

• Software  tools  requirement 

The  number  of  communications,  the  locations  and  operating  shifts  of  the  users, 
and  the  criticality  of  the  problem  communication  per  user  application  must  be 
considered  in  determining  the  Impact  of  an  operation  to  control  more  than  one 
HOL  from  a single  location.  A 16-  or  24-hour  shift  communications  operation 
should  be  considered,  depending  on  the  user  locations  and  the  criticality  of  their 
applications.  For  the  purpose  of  this  analysis,  future  growth  potential  has  been 
considered  an  important  factor.  A generic  impact  assessment  for  the  addition 
of  each  HOL  is  difficult  to  derive.  Generally,  when  maintaining  at  a single 
facility  an  additional  HOL  that  Is  of  like  configuration  to  an  HOL  already  controlled 
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at  that  facility,  the  cost  is  minimal.  In  such  a case  the  primary  cost  factors 
involve  staffing  two  additional  persons  at  an  annual  cost  of  $37 , 809  and  the 
addition  of  one  terminal  device  at  an  annual  cost  of  $6, 000  to  $6, 200,  a total 
annual  increase  of  approximately  $44,000. 

The  impact  of  storage  requirements,  hardware  capabilities,  and  increased 
software  tools  and  compiler  software  must  be  evaluated  as  each  new  HOL  is 
added  to  an  LCF's  control.  As  the  number  and  complexity  of  HOLs  controlled 
by  a single  LCF  increases,  the  requirement  for  supporting  hardware  increases. 
Batch  terminals  and  minicomputer  support  at  the  LCF  should  be  considered  as 
likely  necessities  for  controlling  very  many  multiple  HOLs  from  a single  site, 
so  that  the  host  computer  could  be  relieved  of  many  preprocessing  steps. 
Increased  storage  requirements  would  have  to  be  levied  on  the  host  machine  to 
support  the  added  load  of  software  tools  and  compilers. 

Controlling  all  HOLs  from  a single  LCF  might  even  justify  an  HOL's  own  sep- 
arate host  hardware.  Increased  support  hardware  requirements  cannot  be 
determined  by  simply  increasing  single  HOL  support  hardware  by  a factor  of  the 
total  number  of  HOLs.  Some  sharing  of  capability  can  be  used  up  to  the  point 
where  the  HOL  demands  exceed  the  equipment  capabilities. 

6. 1.  2 MULTIPLE  LCFs 

6. 1.  2. 1 LCFs  for  Each  HOL 

To  control  each  HOL  from  a separate  location  defeats  the  intent  of  the  LCF 
study.  It  presents  the  necessity  of  fully  funding  each  separate  facility  with 
duplicate  staff,  facility,  and  hardware  requirements.  It  also  presents  a 
problem  In  controlling  and  standardizing  the  duplicate  LCFs,  requiring  either 
that  a separate  manager  be  over  all  facilities  or  that  the  manager  of  one  facility 
be  charged  with  administrative  responsibility  for  the  remainder.  Standardized 
procedures  would  help  to  ensure  handling  each  individual  HOL  properly  and 
to  Increase  transferability  of  application  programs  between  facilities  using 
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that  HOL.  However,  each  LCF  would  likely  tend  to  protect  its  own  interests 
and  promote  its  own  HOL.  Outside  the  fact  that  the  LCF  staff  will  have  an 
interest  in  generic  HOLs,  it  is  anticipated  that  they  cannot  avoid  developing 
the  same  self-interested,  parochial  viewpoints  presently  exhibited  by  the  various 
HOL  users.  Such  a position  is  natural  from  a staff  serving  a particular  group 
of  users  and  not  directly  responsible  for  the  interests  and  requirements  of  other 
users. 

Multiple  LCF  facilities,  if  deployed  on  the  basis  of  language  served,  still  have 
to  consider  that  the  users  may  be  physically  located  in  diverse  areas  of  the 
country.  To  provide  LCF  personnel  at  each  user  site  is  an  unmanageable  and 
untenable  solution  that  offers  little  advantage  over  that  of  the  user  having  his 
own  in-house  language  expert.  Occasional  travel  to  the  user  sites  should 
eliminate  any  requirement  for  permanent  on-site  HOL  analysts.  However,  any 
application  judged  critical  enough  to  require  a permanent  on-site  analyst  should 
be  assigned  an  LCF-controlled  analyst  for  whatever  period  is  deemed  necessary. 

6.  1.  2.  2 Alternative  Multiple  LCFs 

Alternatives  to  a separate  LCF  for  each  HOL  are  (1)  to  configure  LCFs  to  sup- 
port similar  languages  or  (2)  to  have  a separate  LCF  to  support  each  of  the  major 
Air  Force  application  areas.  The  first  alternative  seems  logical  and  is  a rec- 
ommended approach  to  increasing  the  initial  LCF.  However,  once  there  is  an 
operable  organization  supporting  more  than  one  HOL,  it  would  seem  a natural 
progression  to  expand  to  additional  HOLs  even  though  those  HOLs  might  not 
share  a familiar  relationship  with  the  original  HOL.  The  second  alternative 
offers  no  advantage  over  controlling  all  HOLs  from  a particular  site,  because 
most  application  areas  use  more  than  one  HOL  and  usually  these  HOLs  support 
different  kinds  of  applications. 
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6.  1.3  SINGLE  LCF  RECOMMENDATION  AND  ADVANTAGES 


AFR  300-10  specifies  three  standard  Air  Force  HOLs,  FORTRAN  IV,  COBOL, 
and  JOVIAL/J3.  The  DOD  High-Order  Language  Working  Group  will  choose  a 
single  standard  HOL  or  at  least  as  few  as  possible.  Recommendations  from  this 
group  will  determine  any  additional  LCF  requirements.  If  the  three  AF  standard 
HOLs  are  considered,  and  the  potential  LCF  considerations  include  the  related 
J73-I  and  J3B,  the  specialized  ATE  HOL,  ATLAS,  and  a possible  yet-to-be 
developed  HOL-like  communications  language,  then  the  anticipated  maximum 
number  of  HOLs  considered  for  control  by  a single  LCF  can  be  limited  to  seven. 
The  advantages  to  operating  from  a single  LCF  to  control  a variety  of  HOLs  are 
many  and  the  most  significant  advantages  are  discussed  below. 

6. 1.  3. 1 Standardization 

By  controlling  a single  HOL,  an  LCF  can  help  to  achieve  standardization  within 
the  user  community  for  that  HOL.  However,  by  controlling  multiple  HOLs, 
especially  those  with  similar  user  applications  supported  by  related  HOLs  or 
versions  of  the  same  HOL,  an  LCF  could  provide  valuable  assistance  in  recog- 
nizing the  requirements  of  the  user  and  matching  those  to  the  capabilities  of 
the  available  HOLs.  In  those  applications  where  little  or  no  present  language 
standardization  or  selection  criteria  exist,  the  LCF  could  provide  a valuable 
insight  into  the  selection  and  adoption  of  appropriate  HOLs.  This  would  not 
only  curb  the  proliferation  of  different  HOLs,  but  also  would  eliminate  the 
unnecessary  use  of  assembly  languages  (where  their  selection  was  one  of 
expediency  rather  than  necessity).  By  funnelling  all  HOL  requirements  to  a 
single  group,  a basic  HOL  requirement  definition  versus  an  HOL  capability  pro- 
file should  evolve  - such  that  desirable  characteristics  of  each  HOL  might  be 
made  available  in  all  HOLs , eventually  consolidating  where  possible. 
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The  LCF  should  become  the  ultimate  source,  cognizant  of:  the  HOLs  used,  the 
shortcomings  of  each  HOL  as  recognizable  from  approved  deviations  or  requests 
for  deviation,  and  applications  not  amenable  to  HOL  use.  Statistics  and  con- 
tinuing studies  can  help  to  provide  a HOL  standardization  guideline  and  capability 
description  that  could  provide  the  baseline  for  future  language  selection  and 
eventual  conversion.  Thus , it  is  important  to  have  one  organization  cognizant 
of  the  broad  spectrum  of  AF  user  languages  and  applications.  Table  6-1  shows 
the  major  languages  used  by  application. 

6. 1.  3.  2 Portability  and  Transferability 

Control  of  HOLs  from  a single  location  enables  the  identification  of  nonstandard 
features  in  the  various  versions , periodic  audit  and  reassessment  of  those 
features , and  a centralized  background  of  knowledge  about  various  target  machine 
requirements.  Application  programs  operable  in  a particular  HOL  version  will 
have  any  nonstandard  features  identified  through  the  compiler,  and  the  LCF  staff 
can  assist  the  new  user  in  determining  whether  those  deviations  are  necessary 
for  his  application  and  target  hardware.  Thus,  the  LCF  can  assist  in  the  trans- 
ferability of  user  software  from  one  user  to  another. 

The  most. difficult  problem  encountered  in  portability  of  HOL  compilers  exists 
in  varied  capabilities  and  idiosyncracies  of  the  target  hardware  configurations. 

The  requirements  for  intimate  knowledge  of  the  various  target  computer  assembly 
languages  or  machine  language  is  of  major  consideration  in  selecting  the  LCF 
staff.  However,  the  possibility  of  staff  selection  by  target  machine  language 
would  defeat  the  purpose  of  the  LCF,  as  the  major  HOLs  are  each  available  on 
a wide  variety  of  hardware  configurations. 

In  the  few  situations  where  an  HOL  is  used  on  a peculiar  target  configuration  not 
applicable  to  any  other  HOLs,  it  is  no  greater  an  impact  to  consider  staffing  an 
additional  support  language  programmer  at  the  LCF  than  to  staff  one  in  the  field. 
The  larger  the  number  of  HOLs  being  supported  by  the  LCF,  the  larger  becomes 
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the  number  of  target  machines.  However,  there  will  be  much  overlap;  therefore, 
the  programmers  could  be  used  according  to  target  language,  each  being  familiar 
with  the  general  language  constructs  of  HOLs  and  working  from  the  predesignated 
semantic  and  syntactic  constructs  verified  and  approved  by  the  HOL  analysis. 

A balance  could  be  obtained  by  cross-training  programmers  in  multiple  target 
languages,  especially  the  lesser-used  ones.  Extensive  development  and  use  of 
cross-compilers  provides  automated  portability.  The  LCF  would  be  tasked  with 
design,  modification,  and  maintenance  of  these  cross-compilers. 

6. 1. 3.  3 Supporting  Software  Tools 

The  development  and  maintenance  of  the  software  tools  required  to  support  the 
LCF  represents  a major  portion  of  the  effort  in  implementation.  To  the  degree 
that  these  tools  can  be  generalized  and  standardized  themselves , such  that  one 
tool  will  handle  more  than  one  HOL,  the  more  cost-effective  and  efficient  will 
be  the  resulting  LCF  implementation.  Development  of  specialized  tools  for  each 
language  should  be  discouraged  much  as  the  LCF  hopes  to  discourage  unnecessary 
proliferation  of  multiple  HOLs  and  specialized  versions  of  HOLs.  This  can 
only  be  accomplished  by  recognizing  at  the  outset  that  combinations  of  HOLs  are 
anticipated. 

While  expediency  and  availability  of  software  tools  to  support  the  initial  LCF 
might  dictate  the  adoption  and  modifications  of  existing  software,  steps  should  be 
taken  to  define  multi-purpose  software  tools  that  can  be  adapted  to  support  a mul- 
tiple HOL  LCF.  Volume  2 of  this  report  describes  the  impact  of  multiple  HOLs 
on  JOCIT,  one  of  the  software  tools  evaluated  in  this  study.  This  tool  already 
has  a generalized  multi-HOL  design  concept  easily  adapted  to  the  JOVIAL  lan- 
guages and,  with  modifications,  to  others. 

6.2  COST  CONSIDERATIONS 

The  cost  of  operating  several  LCFs  versus  operating  a single  LCF  must  be  con- 
sidered with  regard  to  the  impact  on  staffing,  the  physical  facility,  the  hardware 


requirement,  and  the  workload  efficiency.  In  addition,  costs  should  not  take  pri- 
ority over  purposes,  as  there  are  potential  advantages  and  hidden  cost  savings 
through  increased  standardization.  (A  summary  of  increased  costs  for  adding  a 
second  similar  HOL  at  a single  facility  is  shown  in  Table  5-3. ) 

6.  2.  1 STAFFING  CONSIDERATIONS 

Staffing  a single  LCF  facility  to  control  multiple  HOLs  would  not  require  addi- 
tional management.  It  is  recommended  that  several  analysts  be  redesignated 
as  lead  analysts  to  provide  a base  for  forming  language  teams.  These  teams 
should  not  be  fixed,  but  should  be  constructed  to  support  specific  tasks  and 
staffed  by  appropriately  experienced  programmers  and  analysts.  Continuous 
cross-training  of  programmers  and  analysts  should  be  conducted  to  provide 
additional  support  for  the  more  active  HOLs  and  target  hardware. 

Initially,  one  analyst  and  one  programmer  should  be  added  to  the  staff  for  each 
additional  HOL.  However,  for  the  lesser-used  HOLs,  staffing  may  be  shared, 
with  the  increased  staffing  requirement  assigned  to  the  support  of  more  volatile 
HOLs  or  widely  used  target  hardware.  Actual  LCF  operating  experience  will 
help  to  determine  the  final  staffing  requirement.  No  additional  personnel  will 
be  required  to  staff  the  operations  and  librarian  functions.  One  or  two  additional 
documentation  specialists  will  be  required  to  support  multiple  HOLs , but  not 
one  per  HOL.  Documentation  of  like  HOLs  can  be  performed  by  the  same  staff 
member.  An  additional  typist  might  be  required  to  support  the  documentation 
and  clerical  workload. 

6.  2.  2 HOST  HARDWARE  IMPACT 

The  assumption  was  made  in  the  initial  hardware  recommendation  that  sufficient 
time  would  be  available  to  support  a single-HOL  LCF.  The  impact  of  handling 
a larger  number  of  HOLs  for  a larger  number  of  users  would  put  a much  larger 
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requirement  on  this  host  hardware.  It  is  likely  that  sufficient  time  is  not 
available  to  handle  all  of  the  HOLs  addressed  in  this  section.  Based  on  actual 
usage  of  the  initial  LCF,  projected  usage  should  form  the  baseline  for  determin- 
ing whether  a dedicated  host  machine  or,  at  the  least,  a full  batch  terminal 
capability  is  justified.  The  compilers  themselves  and  other  support  software 
should  be  made  host-computer-independent  so  that  they  can  themselves  be  retar- 
geted. The  communications  equipment  interface  is  not  affected  appreciably 
by  the  number  of  HOLs  or  LCF  locations,  as  the  MULTICS  and  GCOS  systems 
can  adequately  handle  the  anticipated  additional  communications  interfaces.  One 
terminal  device  per  HOL  is  recommended  for  each  HOL  controlled  by  a single 
center  and  at  least  one  communications  center  per  physical  LCF  location. 

6.  2.  3 PHYSICAL  FACILITY 

Multiple  LCF  locations  would  require  replicas  of  the  physical  facility  described 
in  this  document.  By  combining  control  into  a single  LCF  the  physical  require- 
ments would  need  to  be  expanded  to  accommodate  a batch  terminal  and  additional 
teletypewriter  terminals.  The  square  foots  o would  have  to  be  increased 
by  the  amount  necessary  to  house  each  addict,  nal  analyst  and  programmer  required 
to  support  each  additional  HOL.  The  supporting  utilities  and  furnishings  to  pro- 
vide for  the  additional  personnel  would  have  to  be  included.  The  resulting  cost 
for  a single  larger  facility  would  be  less  than  for  duplicate  multiple  facilities 
by  virtue  of  the  smaller  staffing. 
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Same  as  (A)  5. 


Table  A- 2.  Manual  Baseline  System  Definition  - II  (2  of  2) 
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Table  A-3.  Manual  Baseline  System  Definition  - 


Table  A-4.  Manual  Baseline  System  Definition  - IV  (1  of  2) 
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Table  A-4.  Manual  Baseline  System  Definition  - IV  (2  of  2) 


User  Intercommunications 


Table  A-5.  Semi- Automated  Telecommunications  Interface  System  Definition  - I (1  of  2) 


address  a particular  function  design/  impact), 

performance  objective  without  the  need  2-3.  Same  as  (A)  2-3. 

for  machine  level  (assembly)  coding  4.  Same  as  (B)  4 (including  analysis  of  user  evaluation 

for  source  code  for  the  function.  of  deficiency). 
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User  input  LCF  correction  codes  from  existing 
compiler/ tool  and  prepare  verification  run  from  cor- 
rected version  and  LCF  supplied  modification  tool. 
User  initiate  verification  from  terminal. 


Table  A-7.  Semi-Automated  Telecommunications  Interface  System  Definition  - 


Process  user  data  (i.  e. , sort,  combine)  and  produce 
desired  statistics. 


Table  A-8.  Semi-Automated  Telecommunications  Interface  System  Definition  - IV  (1  of  2) 


Table  A-8.  Semi- Auto  mated  Telecommunications  Interface  System  Definition  - IV  (2  of  2) 


Figure  A-3.  Semi-Automated  Teleprocessing  Interface  System 
for  LCF  - User  Intercommunications 


other  language). 
Same  as  (A)  5. 


Table  A -9.  Semi-Automated  Teleprocessing  Interface  System  Definition  - I (2  of  2) 


Table  A-10.  Semi -Auto mated  Teleprocessing  Interface  System  Definition  - II  (1  of  2) 
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Table  A-10.  Semi-Automated  Teleprocessing  Interface  System  Definition  - 11  (2  of  2) 
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Figure  A-4.  Automated  Telecommunications/Teleprocessing 
Interface  System  for  LCF  - User  Intercommunications 
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need  for  machine  level  (assembly)  5.  Same  as  (B)  5 (i.  e.  , source  code  approved  or  use 

coding  for  source  code  for  the  function.  other  language. 

6.  Same  as  (A)  5. 


Table  A- 14.  Automated  Telecommunication/Teleprocessing  Interface  System  Definition  - II  (1  of  2) 
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Table  A-15.  Automated  Telecommunicatioo/Teleprocessing  Interface  System  Definition  - 


Table  A-16.  Automated  Telecommunication/Teleprocessing  Interface  System  Definition  - IV 
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B-l.  Cost  Analysis  Worksheet 


Enter— 


Line 

1 The  price  paid  to  the  current  contractor  (contract  cost  less  allowable  dis- 

counts) for  the  product  or  service  being  evaluated,  or  if  not  currently 
contracted,  the  anticipated  price  from  commercial  sources  (Informational 
Quotations). 

а.  “Informational  Quotations"  may  be  used  in  the  cost  analysis  (when  current 
contract  data  is  not  available)  if  there  is  reasonable  assurance  that  the 
contractor  is  capable  and  willing  to  provide  the  product  or  service  for  the 
quoted  price.  See  ASPR  1-309  for  conditions  under  which  contractors  may 
be  solicited  for  quotations  for  information  or  planning  purposes. 

б.  In  some  instances,  the  "going  contract  price”  paid  for  the  same  product 
or  service  by  other  Government  installations  in  the  same  geographical 
area  may  be  used.  This  method  of  costing  contract  performance  should  be 
used  with  discretion  since,  in  most  cases,  specifications  for  products  or 
services  vary  considerably  from  installation  to  installation.  If  this  method 
is  employed,  backup  documentation  must  he  provided  to  substantiate  the 
similarity  of  product  or  service  work  speciiications.  Installations  should 
avail  themselves  of  the  General  Services  Administration,  Small  Business 
Administration,  Purchasing  Offices,  Defense  Contract  Services,  etc.,  in  at- 
tempting to  obtain  comparable  contract  costs. 

e.  “Estimating”  contractual  cost  based  on  equating  contractor  labor-hours, 
methods  and  techniques,  tools  and  materials  to  those  of  the  Government 
is  the  least  acceptable  method  of  determining  contract  cost.  It  should 
only  be  used  if  the  above  described  sources  for  contract  data  are  not 
available  or  price  quotations  from  solicited  commercial  sources  are  deter- 
mined to  be  unreasonable.  If  the  “estimated”  contract  cost  technique  is 
utilised,  full  documentation  must  be  provided,  indicating  methodology  used 
in  arriving  at  the  estimated  cost.  In  addition,  the  rationale  for  the  deter- 
mination that  informational  quotations  are  “unreasonable”  should  be  in- 
cluded in  the  documentation. 

i.  If,  after  making  a decision  to  contract  a function,  firm  offers  are  received 
which  are  higher  than  the  cost  to  perform  the  function  in-house,  recon- 
sideration of  the  decision  is  necessary. 

2 Any  transportation  charges  not  included  elsewhere  in  the  contract  cost 

3 Total  of  all  contract  administration  and  related  costs  which  the  Government 

must  pay  because  of  the  existence  of  the  contract,  but  which  it  would  not 
otherwise  have  to  pay.  This  will  include,  but  will  not  necessarily  be  limited 
to,  costs  for  preparation  of  specifications,  bid  invitations,  pre-award  surveys, 
contract  negotiation  including  award,  inspection  and  acceptance,  and  con- 
tract administration  subsequent  to  award.!  Only  the  additional/incremental 
administration  and  related  costs  will  be  entered  in  this  cost  element  if  the 
contract  is  administered  by  the  installation.  If  the  contract  is  administered 
by  another  agency,  enter  only  those  costs  for  which  the  agency  requires 
reimbursement 

4 Actual  cost  to  the  Government  of  materials  and  supplies  consumed  by  the 

contractor  (including  any  costs  of  transportation,  storage,  etc.),  which 
may  be  involved,  as  described  in  line  13. 

5 Reduction  in  procurement  costs  to  be  made  to  cover  contractor  use  of  Govern- 

ment-furnished equipment  and  facilities.  See  ASPR  7-702.12  for  rental 
factors  to  be  applied  for  contractor  use  of  Government-furnished  equip- 
ment and  facilities.  These  factors  will  be  applied  in  determining  the  reduc- 
tion in  procurement  costs. 
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6 Cost  to  the  Government  of  rehabilitating,  modifying,  or  expanding  Govern- 

ment-owned equipment  or  facilities  provided  to  the  contractor. 

7 Costs  caused  by  incentive  or  premium  provisions  in  the  contract. 

a Cost  of  preparing  a Government  facility  for  standby  status,  and  the  annual 
cost  of  its  standby  maintenance  if  this  results  from  the  commercial 
procurement  action. 

9  Additional  costs  which  would  result  from  commercial  procurement  and  which 
are  not  covered  elsewhere.  Termination  costs  for  Government  personnel 
such  as  premature  retirement  causing  a significant  increase  in  the  retire- 
ment costs  to  the  Government,  severance  pay,  home-owner's  assistance,  and 
moving/relocation  expenses  which  will  actually  be  paid  solely  because  a 
Government  in-house  activity  is  discontinued  will  be  included  when  appro- 
priate. Terminal  leave  costs  are  not  allowed. 

9a  Sum  of  lines  1 through  9. 

10  Cost  of  all  military  personnel  (including  supervisory,  administrative,  support 

and  service  personnel)  who  are  for  work  measurement  or  cost  accounting 
purposes  identified  to  the  function.  This  cost  will  be  computed  in  accordance 
with  AR  37-108  and  DA  Pam  37-6. 

11  a.  Cost  of  civilian  authorizations  which  are  for  work  measurement  or  cost 

accounting  purposes  identified  to  the  function.  The  cost  of  the  civilian  posi- 
tions will  be  gross  annual  pay  as  shown  in  current  pay  tables,  plus  the 
Government’s  contribution  for  civilian  retirement  (or  social  security  if 
applicable  instead  of  civilian  retirement),  disability,  health,  and  life  in- 
surance. These  contributions  should  be  determined  by  multiplying  the  fol- 
lowing percentage  factors  to  the  base  pay: 

Retirement  and  disability  (for  employees  under  Civil  Service  retire- 
ment)*   7.14% 

Health  1.0% 

Life  insurance  . . 3% 

•A  lower  factor  for  retirement  and  disability  should  be  applied  if  a part 
of  the  work  force  would  be  permanently  subject  to  the  Social 
Security  Act,  rather  than  the  Civil  Service  retirement  system.  The 
current  social  security  rate  will  be  used  in  making  cost  studies. 

b.  II  labor  coats  are  determined  on  the  basis  of  direct  labor  hours  applied, 
the  civilian  pay  rate  increased  by  29.34  percent  to  include  leave  and  other 
benefits  would  be  used.  The  29.34  percent  acceleration  of  civilian  pay  rep- 
resents the  average  cost  of  leave  (20.9  percent  for  sick  leave  taken  and  for 
annual,  holiday,  and  other  paid  leave  accruals),  plus  8.44  percent  for  average 
Government  contribution  for  other  benefits. 

12  Sum  of  personnel  costs  which  pertain  to  performance  of  the  function  under 

consideration  and  which  are  not  included  in  lines  10  or  11,  such  as  travel, 
per  diem  and  moving  expenses,  cost  of  living  and  uniform  allowances, 
initial  and  recurring  costs  of  personnel  training. 

13  All  costs  to  the  Government  of  supplies  and  materials  used  in  providing 

a product  or  service.  Include  the  costs  incurred  by  the  installation  for 
transportation,  handling,  storage,  custody  and  protection  of  these  materials 
and  supplies,  and  the  cost  of  utility  services  including  specifically,  electric 
power,  gas,  water,  and  communications  related  to  the  function.  Initial 
startup  costa  for  new  activities  will  also  be  included.  Cost  of  material 
and  supplies  will  include  consideration  for  reasonable  overruns,  spoilage, 
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or  defective  work.  To  cover  central  procurement  and  supply  system  costs 
above  the  installation  level,  a factor  of  5 percent  should  be  added  to  the 
total  cost  of  materials  and  supplies  obtained  through  the  Department  of 
Defense  Depot  Supply  System.  The  5 percent  cost  factor  should  not  be 
applied  to  items  procured  locally  or  through  GSA. 

14  Cost  of  maintenance  and  repair  to  the  buildings,  structures,  grounds,  and 

equipment  used  by  the  function  involved  in  producing  the  goods  or  ser- 
vices. Do  not  include  capital  improvements.  Engineering  estimates  may  be 
used  to  compute  proper  proportions  of  cost  chargeable.  Include  only  those 
maintenance  and  repair  expenses  directly  attributable  to  the  in-house  per- 
formance of  the  service.  Any  maintenance  and  repair  expense  that  would 
continue  whether  the  service  under  study  were  procured  or  were  performed 
in-house  should  be  excluded  from  in-house  cost  of  performance  for  this 
analysis. 

15  Additional  costs  which  are  or  would  be  incurred  at  the  installation  level 

because  of  performing  the  function  in-house.  These  include  the  additional 
(incremental)  costs  of  general  overhead,  such  as  finance  and  accounting, 
personnel,  legal,  local  procurement,  medical  services,  management,  direc- 
tion, and  administration  above  the  organization  performing  the  function. 
This  excludes  costs  of  performing  or  directly  supporting  the  function  re- 
corded on  lines  10  through  14. 

а.  If  the  operation  is  currently  performed  in-house,  the  amount  to  be  reported 
on  line  15  represents  only  those  costs  which  can  be  identified  to  the  support 
of  the  operation  and  which  would  not  be  necessary  if  the  function  were 
not  being  performed.  The  amount  represents  the  actual  dollar  savings  of 
overhead  costs  that  would  be  realized  if  the  operation  were  discontinued. 

б.  If  the  operation  is  not  being  performed  in-house,  i.e„  not  currently  being 
performed,  or  being  performed  by  contract,  the  amount  to  be  entered 
on  line  15  will  represent  those  additional  overhead  costs  that  would  be  in- 
curred by  commencement  of  an  in-house  operation. 

15a  Sum  of  lines  10  through  15. 

16  a.  Federal  taxes  as  appropriate  for  each  industry.  These  include  income  tax 

and  other  Federal  tax  revenue  (except  Social  Security  taxes)  which  would  be 
receive  from  the  commercial  firm  (but  not  from  its  individual  employees  or 
stockholders)  if  the  product  or  service  is  obtained  through  commercial 
sources.  To  compute  these  taxes,  use  the  functional  area  cost  factor  listed 
below.  The  functional  codes  are  from  appendix  A.  These  rates  are  based  on 
ratios  of  taxes  to  income  by  industry.  To  use  the  functional  area  cost  factors; 
multiply  the  cost  shown  on  line  1 by  the  percentage  factor  listed  for  the 
appropriate  functional  code.  The  result  is  the  tax  estimate. 


Functional  area  Coit  factor 

I,  K,  M,  S,  W,  T (except  S725  thru  S730,  T809)  1.83% 

S726  thru  S730,  T809  10.50% 

X931,  936,  940,  942,  943,  944  2.54% 

X932,  934  1 52% 

X933,  938,  939,  937  3.46% 

X935  5.63% 

X941  4.75% 

Z . . 1.83% 


b.  The  actual  experience  of  the  contractor  under  consideration  may,  if  avail- 
able, be  used  to  calculate  tax  estimates. 

e.  If  the  factors  in  a above  are  not  applicable  because  of  special  circumstances, 
estimates  of  corporate  incomes  may  be  based  upon  the  earnings  experience 
of  the  industry,  if  available;  but  if  such  data  are  not  available,  the 
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Quarterly  Financial  Report  of  Manufacturing  Corporations,  published  by 
the  Federal  Trade  Commission  and  the  Securities  and  Exchange  Commis- 
sion may  be  consulted.  Alternatively,  the  Internal  Revenue  Service  Publica- 
tion No.  16,  Corporation  Income  Tax  Returns  may  be  used.  Assistance 
from  appropriate  Government  regulatory  agencies  may  be  obtained  in  esti- 
mating taxes  from  regulated  industries. 

а.  New  or  additional  facilities  or  equipment.  Depreciation  should  be  computed 
as  a cost  for  any  new  or  additional  facilities  or  equipment,  and  for  any 
rehabilitation,  modification  or  expansion  of  existing  facilities  or  equipment 
which  will  be  required  if  a Government  activity  is  started  or  continued. 
In  computing  the  depreciation  cost  of  new  or  additional  facilities  or  equip- 
ment to  be  acquired  if  a Government  activity  is  started  or  continued, 
and  in  determining  the  comparative  costs  under  lease-purchase 
alternatives,  appropriate  recognition  should  be  given  to  estimated  sal- 
vage or  residual  values  of  the  facilities  or  equipment.  The  Internal  Revenue 
Service  publication,  Depreciation:  Guidelines  and  Rules  may  be  used  in 
computing  depreciation.  A condensed  listing  of  these  depreciation  rates  is 
provided  in  figure  4-2.  However,  these  rates  are  maximums  to  be  used 
only  for  reference  purposes  and  only  when  more  specific  depreciation  rate 
are  not  available.  Accelerated  depreciation  rates  permitted  in  some  in- 
stance by  the  Internal  Revenue  Service  will  not  be  used. 

б.  Existing  equipment  or  facilities  (“opportunity  costs”).  Depreciation  will 
not  be  allocated  for  facilities  acquired  by  the  Government  before  the  cost 
comparison  study  is  started.  However,  if  reliance  upon  a commercial 
source  will  cause  Goverr.ment-owncd  equipment  or  facilities  to  become  avail- 
able for  other  Federal  use  or  for  disposal  as  surplus,  the  cost  comparison 
analysis  should  include  as  a cost  in  the  first  year  of  operation  of  the  Govern- 
ment activity  an  appropriate  amount  based  upon  the  estimated  current 
market  value  of  such  equipment  or  facilities.  (Footnote  and  explain.)  This 
amount  represents  an  opportunity  cost,  which  is  the  money  the  Govern- 
ment would  lose  by  continuing  this  activity  with  its  existing  equipment 
and  facilities.  If  the  Government  would  discontinue  the  function,  it  would 
have  an  opportunity  to  recoup  certain  moneys  for  its  equipment  and  facili- 
ties. 

Computed  interest  for  any  new  or  additional  capital  to  be  invested  by  the 
Government.  This  entry  is  used  to  estimate  the  interest  the  Government 
would  have  to  pay  when  borrowing  to  make  the  capital  investment.  Interest 
for  the  first  year  of  cost  comparison  will  be  computed  on  the  full  value 
of  the  new  or  additional  capital  investment.  Interest  for  subsequent 
years  will  be  computed  on  the  value  of  the  capital  investment  reduced  by 
annual  depreciation.  The  rate  of  interest  will  be  the  current  interest  for 
long  term  Treasury  obligations.  Yield  rates  are  reported  in  the  current 
issue  Of  the  Treasury  Bulletin,  Table  1,  Average  Yields  of  Treasury  and 
Corporate  Bonds  by  Periods,  and  will  be  used  in  these  computations  re- 
gardless of  any  rates  of  interest  which  may  be  used  by  the  agency  for  other 
purposes. 

Costs  incurred  or  to  be  incurred  by  the  activity  which  results  from  uninsured 
losses  caused  by  fire  or  other  hazards,  insurance  premiums  and  settlement 
of  loss  and  damage  claims,  and  the  cost  of  claims  paid  through  the 
Bureau  of  Employees’  Compensation.  To  simplify  calculation  of  these  total 
insurance  costs,  they  should  be  estimated  by  applying  a factor  of  0.3 
percent  of  all  Government  costs  shown  on  line  16a. 

Additional  indirect  costs  incurred  or  to  be  incurred  because  commercial  pro- 
curement is  not  used.  These  indirect  costs  consist  of  various  central 
administrative  services  above  the  installation  level,  such  as  centralized 
accounting,  personnel,  and  legal  assistance  or  other  Government-wide  ser- 
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20a 

21 


22 

23 

24 

25 

26 
26a 


vices  of  such  organizations  as  the  Public  Buildings  Service  and  the  General 
Services  Administration.  It  is  not  always  feasible  to  determine  the  extent 
to  which  the  costs  of  these  types  of  central  services  should  be  allocated 
to  a Government  commercial  or  industrial  activity  on  an  individual  basis. 
To  cover  these  services,  a cost  factor  of  2 percent  may  be  applied  to 
line  15a  and  the  result  will  be  entered  on  line  20  of  the  worksheet.  In 
lieu  of  the  2-percent  factor,  a higher  or  iower  amount  may  be  used  in 
unusual  cases  provided  the  basis  for  the  substitution  is  fully  justified  in 
the  cost  comparison. 

Sum  of  lines  10  through  15  and  16  through  20. 

Actual  reimbursable  costs  or,  in  the  case  of  a proposed  new  support  agree- 
ment, the  anticipated  reimbursable  costs  for  products/services  furnished 
by  another  installation,  another  service,  or  another  governmental  depart- 
ment or  agency. 

Note.  All  entries  recorded  in  lines  22  through  26  will  represent  those 
additional  costs  incurred  by  the  installation  receiving  support  not  included 
in  line  21  and  which  it  would  not  have  incurred  without  the  existence  of 
the  support  agreement. 

Actual  or  anticipated  administrative  costs  which  the  installation  incurs  or 
will  incur  because  of  the  existence  of  a support  agreement  with  another 
installation. 

Actual  or  anticipated  transportation  and  travel  costs  incurred  by  the  installa- 
tion receiving  support. 

Actual  or  anticipated  costs  incurred  by  the  receiving  installation  for  materials, 
supplies,  utilities  and  other  services  furnished  to  and  used  by  the  supporting 
installation  in  producing  the  product  or  performing  the  service. 

Actual  or  anticipated  costs  of  personnel  assigned  to  the  supporting  installa- 
tion, if  its  manpower  requirements  are  provided  on  a joint  staff  basis. 

Any  additional  costs,  not  included  in  lines  21  through  25,  which  are  or  will 
be  incurred  by  the  installation  receiving  support. 

Sum  of  lines  21  through  26. 
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BASE  UNITS: 

_ Quantity 


Unit 


length 

mass 

time 

electric  current 
thermodynamic  temperature 
amount  of  substance 
luminous  intensity 

SUPPLEMENTARY  UNITS: 

plane  angle 
solid  angle 

DERIVED  UNITS: 
Acceleration 

activity  (of  a radioactive  source) 

angular  acceleration 

angular  velocity 

area 

density 

electric  capacitance 

electrical  condui  lance 

electric  field  strength 

electric  inductance 

electric  potential  difference 

electric  resistanc  e 

electromotive  force 

energy 

entropy 

forte 

frequency 

illuminance 

luminance 

luminous  flux 

magnetic  field  strength 

magnetic  flux 

magnetic  flux  density 

magnetomotive  force 

power 

pressure 

quantity  of  electricity 
quantity  of  heat 
radiant  intensity 
specific:  heat 
stress 

thermal  conductivity 
velocity 

viscosity,  dynamic. 

viscosity,  kinematic 

voltage 

volume 

wavenumber 

work 


metre 

kilogram 

second 

ampere 

kelvin 

mole 

candela 


radian 

steradian 


metre  per  second  squared 

disintegration  per  second 

radian  per  second  squared 

radian  per  sec  ond 

square  metre 

kilogram  per  cubic:  metre 

farad 

siemens 

volt  per  metre 

henry 

volt 

ohm 

volt 

joule 

joule  per  kelvin 

newton 

hertz 

lux 

candela  per  square  metre 
lumen 

ampere  per  metre 

weber 

tesla 

ampere 

watt 

pascal 

coulomb 

joule 

watt  per  steradian 

joule  per  kilogram-kelvin 

pascal 

watt  per  metre-kelvin 
metre  per  second 
pascal-second 
square  metre  per  second 
volt 

cubic  metre 
reciprocal  metre 
joule 


SI  Symbol  Formula 


m 

kg 

s 

A 

K 

mol 

cd 

... 

rad 

sr 

mis 

(disintegration  )/s 
rad/s 

rad/s 

m 

kg/m 

F 

A-s/V 

S 

Art/ 

V/m 

H 

V-s/A 

V 

W/A 

V/A 

V 

W/A 

1 

N-m 

)/K 

N 

kg-m/s 

Hz 

(cycle)/s 

lx 

im/m 

cd/m 

Im 

cd-«r 

Aim 

Wb 

V-s 

T 

Wbrtn 

A 

W 

J/a 

Pa 

N/m 

C 

A-s 

1 

N-m 

W/sr 

I'kg-K 

Pa 

N/m 

W/m-K 

m/s 

Pa-s 

m/s 

V 

W/A 

m 

i 

(wave)/m 

N-m 

SI  PREFIXES: 


Multiplic  ation  Factors 


Prefix 


1 000  0011  000  000  = 

10” 

tera 

1 000  000  000  = 

10* 

gig* 

t flOO  000  = 

10* 

mega 

1 000  = 

10’ 

kilo 

100  * 

10» 

hecto* 

to  = 

10' 

deka* 

0 1 = 

10-' 

decl* 

0 01  = 

10-* 

cnntf* 

0 001  = 

10-' 

mill! 

0 000  001  = 

10*  » 

micro 

0.000  000  001  = 

10- * 

nano 

0.000  000  000  001  ’ 

10- '» 

itta» 

0.000  000  000  000  001  = 

in-” 

fnmto 

0.000  000  000  000  000  001 

It)-" 

alto 

* To  be  avoided  where  possible 


SI  Symbol 

T 

C 

M 

k 

h 

da 

d 

e 

nt 

M 

n 

F 

M 


j 


r 


